From: Brian Smithson (brian.smithson@ricoh-usa.com)
Date: Mon Feb 02 2009 - 14:05:59 EST
I agree that we may have bitten off more than we can (or should) chew
with the cipher suite/length attributes. It's a general security problem
that applies to all kinds of devices. Until it is solved by a wider
community, perhaps 3rd party certification or customer configuration
attributes would be the best choice to allow customers to set and
enforce policies having to do with encryption etc.
-- Regards, Brian Smithson PM, Security Research PMP, CISSP, CISA, ISO 27000 PA Advanced Imaging and Network Technologies Ricoh Americas Corporation (408)346-4435Randy Turner wrote: > > This was basically my feeling when I was considering exactly what we > were proposing... > > If we're trying to come up with a minimum security level for a > hardcopy device, then it needs > to be expressed or modeled after something that can be applied > generally to all security functionality > within the device, otherwise we've left something out, and if we've > left something out, how valuable > is the "minimum security" assurance if there's a gaping hole somewhere > in a device that we didn't take > into account. > > If if we just address encryption, we've left out digital signatures > and certificate validation. > > Some devices, when they receive an SSL server cert, may not even do > any validation on that cert, or > they may only do time-stamp checks but not revocation checks (like > some browsers were known to do). > I would consider this a fairly major security issue. And this is just > one example. > > So I guess what I'm saying is that coming up with a minimum security > "profile" for a device is going to > be a "sticky wicket", and would probably end up consisting of several > multi-valued attributes potentially. > > I'm beginning to re-think our earlier discussion about having an > attribute that says that this device has > been "certified" to a particular assurance level or minimum security > profile, by a 3rd party. And just setting > this attribute to "yes" or "no". And let the 3rd party certification > house worry about actually examining all > the cryptography in the product to see if it meets some standard. > > And Dave, regarding your analysis of missing enums (Counter mode), > there are enumerations for GCM, > which is "Galois Counter Mode". I don't expect any other form of > counter mode to be added anytime soon, at > least it's not under discussion on the mailing lists. But you bring up > the larger point of applicability of our attributes, > which I hope I have articulated further in this email. > > Thanks, > Randy > > > On Feb 2, 2009, at 7:50 AM, Dave Whitehead wrote: > >> 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@amalfisy >> >> stems.com> To >> Sent by: ids@pwg.org >> >> owner-ids@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@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 : Mon Feb 02 2009 - 14:05:22 EST