From: Ira McDonald (blueroofmusic@gmail.com)
Date: Sun Feb 01 2009 - 21:40:55 EST
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 - 21:41:02 EST