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 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 Sun, Feb 1, 2009 at 9:49 PM, Randy Turner <rturner at 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 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 Sun, Feb 1, 2009 at 7:16 PM, Randy Turner <rturner at 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 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>