From: Ira McDonald (blueroofmusic@gmail.com)
Date: Sun Feb 01 2009 - 22:29:39 EST
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 : Sun Feb 01 2009 - 22:29:46 EST