From: Randy Turner (rturner@amalfisystems.com)
Date: Sun Feb 01 2009 - 22:30:32 EST
OK, let me see if I understand how both values would be used by an
implementation.
The implementation could have a table with two columns:
[SSL/TLS enumeration] [Key-Length]
Ideally, the table would be ordered on "cryptographic strength",
minimum to maximum.
If both parameters are specified (SSL/TLS enum and minimum key
length), then an implementation would perform the
following procedure during setup of a security association with a peer:
1. Search the table for a row with the SSL/TLS enumeration equal to
the configured enumeration.
2. If no such row exists, what do we do?
We could bail and tell the admin the device is misconfigured OR we
could
3. If the row's "key-length" column >= the configured minimum key
length, then don't negotiate anything less than the row's enumeration.
We're done.
4. continue searching until end of table
It's possible that the device supports both configuration parameters,
but only the minimum key length is specified. In this case, the
algorithm would just search
the table for the first row that has a "key-length" column >= the
minimum configured key length. In this case, we wouldn't negotiate
anything less than the row's
SSL/TLS enumeration.
It's also possible that the device supports both configuration
parameters, but only the SSL/TLS enumeration parameter is configured.
In this case, the
implementation doesn't negotiate anything less than the specified SSL/
TLS enumeration parameter.
I think I may see a reason for both parameters, but devices should
support setting both parameters, or only one of the two and still
understand what to do....
Randy
On Feb 1, 2009, at 6:49 PM, Randy Turner 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 : Sun Feb 01 2009 - 22:30:40 EST