I think it should be a "general" statement since there are other
applications that may not use TLS.
Also, the IANA registry for TLS cipher suites does not seem to cover the
entire universe. For example, there are no enumerations for AES in Counter
mode. (Or maybe I'm just having problems finding them ...) How would we
specify 128-bit AES in CTR mode?
That said, and accounting for Ira's definition of "secure," I'm wondering
if we need more information. Should we attach security parameters to
individual applications? (ouch!) Should the Min_Cipher_Suite element be a
list of application:ciphersuite entries?
Or, should we just throw up our hands and say this is larger than just MFDs
and should be handled somewhere else?
dhw
David H. Whitehead
Development Engineer
Lexmark International, Inc.
859.825.4914
davidatlexmarkdotcom
Randy Turner
<rturner at amalfisy
stems.com> To
Sent by: ids at pwg.orgowner-ids at pwg.org cc
Subject
02/01/2009 11:30 Re: IDS> Min_Cipher_Suite and
PM Min_Cipher_Key_Length attributes
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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>