IDS> Min_Cipher_Suite and Min_Cipher_Key_Length attributes

IDS> Min_Cipher_Suite and Min_Cipher_Key_Length attributes

IDS> Min_Cipher_Suite and Min_Cipher_Key_Length attributes

Randy Turner rturner at amalfisystems.com
Sun Feb 1 17:06:33 EST 2009


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 at 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 at 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
>>
>>
>>
>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2433 bytes
Desc: not available
Url : http://www.pwg.org/archives/ids/attachments/20090201/ae6fbfe6/smime.bin


More information about the Ids mailing list