From: Randy Turner (rturner@amalfisystems.com)
Date: Mon Feb 02 2009 - 12:55:23 EST
This was basically my feeling when I was considering exactly what we
were proposing...
If we're trying to come up with a minimum security level for a
hardcopy device, then it needs
to be expressed or modeled after something that can be applied
generally to all security functionality
within the device, otherwise we've left something out, and if we've
left something out, how valuable
is the "minimum security" assurance if there's a gaping hole somewhere
in a device that we didn't take
into account.
If if we just address encryption, we've left out digital signatures
and certificate validation.
Some devices, when they receive an SSL server cert, may not even do
any validation on that cert, or
they may only do time-stamp checks but not revocation checks (like
some browsers were known to do).
I would consider this a fairly major security issue. And this is just
one example.
So I guess what I'm saying is that coming up with a minimum security
"profile" for a device is going to
be a "sticky wicket", and would probably end up consisting of several
multi-valued attributes potentially.
I'm beginning to re-think our earlier discussion about having an
attribute that says that this device has
been "certified" to a particular assurance level or minimum security
profile, by a 3rd party. And just setting
this attribute to "yes" or "no". And let the 3rd party certification
house worry about actually examining all
the cryptography in the product to see if it meets some standard.
And Dave, regarding your analysis of missing enums (Counter mode),
there are enumerations for GCM,
which is "Galois Counter Mode". I don't expect any other form of
counter mode to be added anytime soon, at
least it's not under discussion on the mailing lists. But you bring up
the larger point of applicability of our attributes,
which I hope I have articulated further in this email.
Thanks,
Randy
On Feb 2, 2009, at 7:50 AM, Dave Whitehead wrote:
> I think it should be a "general" statement since there are other
> applications that may not use TLS.
>
> Also, the IANA registry for TLS cipher suites does not seem to cover
> the
> entire universe. For example, there are no enumerations for AES in
> Counter
> mode. (Or maybe I'm just having problems finding them ...) How
> would we
> specify 128-bit AES in CTR mode?
>
> That said, and accounting for Ira's definition of "secure," I'm
> wondering
> if we need more information. Should we attach security parameters to
> individual applications? (ouch!) Should the Min_Cipher_Suite
> element be a
> list of application:ciphersuite entries?
>
> Or, should we just throw up our hands and say this is larger than
> just MFDs
> and should be handled somewhere else?
>
> dhw
>
> David H. Whitehead
> Development Engineer
> Lexmark International, Inc.
> 859.825.4914
> davidatlexmarkdotcom
>
>
>
> Randy Turner
> <rturner@amalfisy
>
> stems.com> To
> Sent by: ids@pwg.org
> owner-
> ids@pwg.org cc
>
>
> Subject
> 02/01/2009 11:30 Re: IDS> Min_Cipher_Suite and
> PM Min_Cipher_Key_Length attributes
>
>
>
>
>
>
>
>
>
>
> I have a scope question,
>
> Using our "minimum security" attribute(s), do we want to specify the
> minimum cryptographic strength
> for just hardcopy applications using TLS/SSL? Or do we want to give
> "general" guidance no matter
> what protocol the device uses when performing cryptography?
>
> Certainly SSL/TLS would knock out a good bit, but I was wondering
> about other cryptographic applications on a
> device that might not use SSL/TLS as it's cryptographic session
> establishment protocol.
>
> ?
>
> R.
>
> On Feb 1, 2009, at 7:29 PM, Ira McDonald wrote:
>
>> Hi Randy,
>>
>> Sorry - agreed - the key length, encryption algorithm (DES),
>> and mode (CBC) are all in the single TLS token.
>>
>> Cheers,
>> - Ira
>>
>> Ira McDonald (Musician / Software Architect)
>> Chair - Linux Foundation Open Printing WG
>> Blue Roof Music/High North Inc
>> email: blueroofmusic@gmail.com
>> winter:
>> 579 Park Place Saline, MI 48176
>> 734-944-0094
>> summer:
>> PO Box 221 Grand Marais, MI 49839
>> 906-494-2434
>>
>>
>>
>> On Sun, Feb 1, 2009 at 9:49 PM, Randy Turner <rturner@amalfisystems.com
>>> wrote:
>>>
>>> All I'm saying is if you want to use TLS/SSL enumerations to
>>> designate
>>> cryptoalgorithms, then
>>> use don't need the minimum key length because the key length is
>>> included in
>>> the enumeration.
>>>
>>> Randy
>>>
>>>
>>> On Feb 1, 2009, at 6:40 PM, Ira McDonald wrote:
>>>
>>>> Hi,
>>>>
>>>> Randy - you missed my point - EVERY open port on the whole device
>>>> has to use TLS/SSL (or SSH or whatever) with the same minimum
>>>> strength encryption algorithm (DES, 3DES, AES, etc.) and same
>>>> minimum key length, or the device is *not secure* - period.
>>>>
>>>> Different encrytion and secure hash algorithms offer different
>>>> strengths
>>>> of protection when using the same key length.
>>>>
>>>> And I don't favor dropping the use of the IANA TLS registry - it's
>>>> used
>>>> by all SSL and TLS implementations and many other IETF protocols
>>>> and can be reasonably mapped to other IANA security token
>>>> registries.
>>>>
>>>> Cheers,
>>>> - Ira
>>>>
>>>> Ira McDonald (Musician / Software Architect)
>>>> Chair - Linux Foundation Open Printing WG
>>>> Blue Roof Music/High North Inc
>>>> email: blueroofmusic@gmail.com
>>>> winter:
>>>> 579 Park Place Saline, MI 48176
>>>> 734-944-0094
>>>> summer:
>>>> PO Box 221 Grand Marais, MI 49839
>>>> 906-494-2434
>>>>
>>>>
>>>> On Sun, Feb 1, 2009 at 7:16 PM, Randy Turner <rturner@amalfisystems.com
>>>>>
>>>> wrote:
>>>>>
>>>>> Scratch my comment about IKE (and IPSEC) below, as RFC 4308 seems
>>>>> to
>>>>> suggest
>>>>> that IKE(and V2) use a multi-valued negotiation type which
>>>>> indicates more
>>>>> than just encryption strength....
>>>>>
>>>>> R.
>>>>>
>>>>>
>>>>> On Feb 1, 2009, at 2:06 PM, Randy Turner wrote:
>>>>>
>>>>>>
>>>>>> The "model" that we've discussed in the past is having a "scale"
>>>>>> of
>>>>>> cryptographic protection, from weak to strong.
>>>>>> And based on the model, I think the idea of these attributes was
>>>>>> to be
>>>>>> able to specify a "minimum" cryptographic
>>>>>> requirement for the device.
>>>>>>
>>>>>> The "model" that was originally referenced was that using SSL/
>>>>>> TLS, and
>>>>>> the
>>>>>> corresponding TLS/SSL IANA enumerations.
>>>>>>
>>>>>> If we're going to stick to the SSL/TLS enumerations, then the
>>>>>> minimum
>>>>>> key-size wouldn't be needed because they offer no
>>>>>> benefit to implementers - TLS/SSL only negotiates based on the
>>>>>> enumerations and not a separate parameter called "key length". I
>>>>>> believe
>>>>>> (don't quote me on this) that IKE does the same thing when
>>>>>> negotiating
>>>>>> IPSEC security associations.
>>>>>>
>>>>>> If we're going to just have a "minimum" key length for
>>>>>> encryption, then
>>>>>> you wouldn't need to reference the enumerations.
>>>>>>
>>>>>> I think there are 4 alternatives:
>>>>>>
>>>>>> 1. Just use a minimum key length, and we don't worry about a
>>>>>> particular
>>>>>> "model" for levels of encryption, such as SSL/TLS
>>>>>>
>>>>>> 2. Just use the enumerations from the TLS/SSL IANA registry, and
>>>>>> dump
>>>>>> the
>>>>>> minimum key length.
>>>>>>
>>>>>> 3. Dump both and move on
>>>>>>
>>>>>> 4. Come up with a new proposal based on another set of
>>>>>> enumerations
>>>>>> describing cryptographic algorithms
>>>>>>
>>>>>> My preference would be 2 or 3, since the guidance and direction
>>>>>> for
>>>>>> implementers is very straightforward and unambiguous (being an
>>>>>> OpenSSL implementer myself)
>>>>>>
>>>>>> Randy
>>>>>>
>>>>>>
>>>>>> On Feb 1, 2009, at 10:52 AM, Ira McDonald wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Just my two cents, but, I'd urge that either:
>>>>>>>
>>>>>>> (1) Both attributes stay REQUIRED; or
>>>>>>> (2) Both attributes are deleted entirely from IDS.
>>>>>>>
>>>>>>> Having said that, the FIRST principal of security
>>>>>>> audits is that EVERY network protocol has to be
>>>>>>> secured on a device and the weakest security
>>>>>>> configured for any of those network protocols is
>>>>>>> the security rating of the entire device.
>>>>>>>
>>>>>>> Secure devices do NOT send or receive unsecured
>>>>>>> email over SMTP (for example).
>>>>>>>
>>>>>>> MFDs shouldn't claim to be secure if they aren't.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> - Ira
>>>>>>>
>>>>>>> Ira McDonald (Musician / Software Architect)
>>>>>>> Chair - Linux Foundation Open Printing WG
>>>>>>> Blue Roof Music/High North Inc
>>>>>>> email: blueroofmusic@gmail.com
>>>>>>> winter:
>>>>>>> 579 Park Place Saline, MI 48176
>>>>>>> 734-944-0094
>>>>>>> summer:
>>>>>>> PO Box 221 Grand Marais, MI 49839
>>>>>>> 906-494-2434
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jan 31, 2009 at 7:08 PM, Randy Turner
>>>>>>> <rturner@amalfisystems.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I think so....when you actually code TLS connections using
>>>>>>>> OpenSSL,
>>>>>>>> you
>>>>>>>> can
>>>>>>>> specify a minimum cipher suite to be negotiated...only the
>>>>>>>> cipher
>>>>>>>> suite
>>>>>>>> enumeration is specified, so I think it's ok to use just the
>>>>>>>> enumerations.
>>>>>>>> R.
>>>>>>>> On Jan 31, 2009, at 4:03 PM, Brian Smithson wrote:
>>>>>>>>
>>>>>>>> Thanks, Randy.
>>>>>>>>
>>>>>>>> So is our key length attribute redundant?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Regards,
>>>>>>>> Brian Smithson
>>>>>>>> PM, Security Research
>>>>>>>> PMP, CISSP, CISA, ISO 27000 PA
>>>>>>>> Advanced Imaging and Network Technologies
>>>>>>>> Ricoh Americas Corporation
>>>>>>>> (408)346-4435
>>>>>>>>
>>>>>>>> Randy Turner wrote:
>>>>>>>>
>>>>>>>> Hi Brian,
>>>>>>>> I think the IANA registry actually has the key length
>>>>>>>> specified as
>>>>>>>> part
>>>>>>>> of
>>>>>>>> the suite enumeration.
>>>>>>>> Examples are:
>>>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA256
>>>>>>>> TLS_RSA_WITH_AES_256_CBC_SHA256
>>>>>>>> There are other suites that don't specify numeric key sizes,
>>>>>>>> but in
>>>>>>>> these
>>>>>>>> cases, the algorithm itself
>>>>>>>> (3DES for example) work with a specific key size that doesn't
>>>>>>>> vary.
>>>>>>>> In this case, we may be able to just specify that we're
>>>>>>>> talking about
>>>>>>>> a
>>>>>>>> minimum suite, with a reference to RFC 5246 and
>>>>>>>> the IANA registry itself.
>>>>>>>> Randy
>>>>>>>>
>>>>>>>> On Jan 30, 2009, at 6:26 PM, Brian Smithson wrote:
>>>>>>>>
>>>>>>>> I am still wondering how these two attributes can be used in
>>>>>>>> practice.
>>>>>>>> I
>>>>>>>> know that we can uniquely identify cipher suites using the IANA
>>>>>>>> registry, but is there an authoritative source to specify that
>>>>>>>> one
>>>>>>>> suite
>>>>>>>> is "more minimum" than another? And if you consider different
>>>>>>>> key
>>>>>>>> lengths that might be acceptable for a given suite, then can
>>>>>>>> we really
>>>>>>>> say that suite X is more minimum than suite Y even if an HCD
>>>>>>>> supports
>>>>>>>> a
>>>>>>>> relatively long key length for X but only supports a
>>>>>>>> relatively short
>>>>>>>> one for Y?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Regards,
>>>>>>>> Brian Smithson
>>>>>>>> PM, Security Research
>>>>>>>> PMP, CISSP, CISA, ISO 27000 PA
>>>>>>>> Advanced Imaging and Network Technologies
>>>>>>>> Ricoh Americas Corporation
>>>>>>>> (408)346-4435
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
>
This archive was generated by hypermail 2.1.4 : Mon Feb 02 2009 - 12:55:31 EST