From: Randy Turner (rturner@amalfisystems.com)
Date: Sun Feb 01 2009 - 21:49:26 EST
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 - 21:49:33 EST