From: Randy Turner (rturner@amalfisystems.com)
Date: Sun Feb 01 2009 - 23:30:09 EST
I have a scope question,
Using our "minimum security" attribute(s), do we want to specify the
minimum cryptographic strength
for just hardcopy applications using TLS/SSL? Or do we want to give
"general" guidance no matter
what protocol the device uses when performing cryptography?
Certainly SSL/TLS would knock out a good bit, but I was wondering
about other cryptographic applications on a
device that might not use SSL/TLS as it's cryptographic session
establishment protocol.
?
R.
On Feb 1, 2009, at 7:29 PM, Ira McDonald wrote:
> 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 - 23:30:17 EST