Re: 2nd try at Algorithms Section

Hi,

From:  "Jim Schaad" <jimsch5@home.com>
Reply-To:  <jimsch@exmsft.com>
To:  "'Donald E. Eastlake 3rd'" <dee3@torque.pothole.com>
Cc:  <xml-encryption@w3.org>, <lde008@dma.isgmot.com>
Date:  Wed, 6 Jun 2001 11:32:10 -0700
Message-ID:  <002901c0eeb6$fff97150$0d00a8c0@soaringhawk.net>
In-Reply-To:  <200106061722.NAA0000041614@torque.pothole.com>

>Donald,
>
>Its always nice to be appreciated.
>
>> -----Original Message-----
>> From: xml-encryption-request@w3.org
>> [mailto:xml-encryption-request@w3.org]On Behalf Of Donald E. Eastlake 3rd
>> Sent: Wednesday, June 06, 2001 10:23 AM
>> To: jimsch@exmsft.com
>> Cc: xml-encryption@w3.org; lde008@dma.isgmot.com
>> Subject: Re: 2nd try at Algorithms Section
>>
>> [I know there are later comments in this thread but I'm going to
>> finish off this response before diving into them...]
>>
>> Hi Jim,
>>
>> It's great to get such extensive and detailed commentary!
>>
>> From:  "Jim Schaad" <jimsch5@home.com>
>> Reply-To:  <jimsch@exmsft.com>
>> To:  <xml-encryption@w3.org>, <Donald.Eastlake@motorola.com>
>> Date:  Tue, 5 Jun 2001 02:21:19 -0700
>> Message-ID:  <001701c0eda0$e1da3c20$0d00a8c0@soaringhawk.net>
>>
>> >Donald,
>> >
>> >Here are my comments on your draft.
>> >
>> >4.  General:  I have not looked at the DigSig draf recently, however I
>> >would like to know which name form is going to be used for this algorithm:
>> >The one based on the xmlenc draft (xmlenc#3des) or the "urn" version used in
>> >the examples draft.  I think this item needs discussion.
>>
>> I believe that, consistent with the XMLDSIG draft, we should use all
>> URLs that can point to documnetation.
>
>Having looked at the digsig draft for the first time in a long while, I see
>that these are consistant names and agree they are fine.  Joseph needs to
>update the examples to use this name form.
>
>> >5.  Section 5.3.1:  I found the discussion of the 3DES key processing to be
>> >very confusing.  After reading the text I found that I needed to change my
>> >current key handling significantly as the "parity" bits are no longer
>> >carried in the key value.  Currently implementations have a 192-bit key
>> >value of which 168-bits are significant key information. Processing the way
>> >it is currently described is very hard as every 8-th bit is parity and needs
>> >to be inserted in the 56-bit key to make a 64-bit key value.  This text
>> >should be altered by removing the discussion on EDE entirely as this is
>> >covered in the FIPS and ANSI documents.
>>
>> I think you mean 5.2.1.
>>
>> There are reasons for tossing the silly parity bits. Their presence
>> leads to additional complexity in generating them and sometimes in the
>> harmful checking of them. (Note the famous case of the secure telnet
>> implementation which generated DES keys with all zero parity bits but
>> then called crypto routines which ignored the key if the parity was
>> wrong and just encrypted with a zero DES key. This meant that 255 out
>> of 256 times, you wre encrypting with a constant known key. Of course
>> the data looked random and this implementation interoperated fine with
>> itself,which was how it was normally used. It was in use for years
>> before anyone noticed.) However, if it is really that inconvenient for
>> many people to eliminate the parity bits due to the crypto library
>> they are using or whatever, I'll change it.
>>
>> I see no harm in the one sentence which tell you what's going on with
>> EDE. This document has some limited details on algorithms so someone
>> generally familiar with modern crytography can tell what's going on,
>> rather than a terse "algorihm X as defined in document Y".
>
>Implementers please comment on this.  I know that it would lead to potential
>problems when used with the Microsoft CryptoAPI as the existing code used
>with CMS does not operate in this manner.
>
>> >6. Section 5.3.1:  I firmly believe that changing the chaining mode changes
>> >the algorithm and a new URI should be assigned.  I also would like
>> >information such as the chaining mode to be included in the URI so I prefer
>> >the text "xmlenc#3des-ede-cbc" for the name.
>>
>> This is a spectrum. After all, why stop with 3des-ede-cbc? What about
>> the padding? What about the type of CBC? As I recall, there are really
>> four different ways to do CBC.  I really can't see any reason anyone
>> would bother with other that EDE so I'm not willing to stick that in
>> unless there is a clear consensus to do so.  I suppose we could add
>> "-cbc" but I'm inclined to have it be the default and add a suffix
>> if/when a different chaining mode algorithm is ever defined.
>
>Honestly, I have no problems with specifing the padding mode as well.  I can
>agree with omitting the -ede but would prefer to see the ECB as the omitted
>chaining mode if there was one.  I can live with omitting the -cbc but do
>not care for it.

OK, I'll add cbc.

>> >7. Section 5.3.1:  Can somebody summerize for me the basis on which it was
>> >decided to place the IV in the cipher text.  There are three alternatives
>> >here and I would like to know the rational behind the decision.  1) Put the
>> >IV in the EncryptionMethod element, 2) Prefix the IV to the CipherData, 3)
>> >prefix one block of random data to the plain text and use an IV of zero
>> >(tossing that block on decrypt).
>>
>> I don't remember exactly but apparently it was felt to more tightly
>> link the IV and the cipher text to avoid confusion or any temptation
>> to use the same IV element for more than one ciphertext or
>> something. It's also less verbose.  I really don't care on this point
>> and would not mind an <IV/> parameter but was just following what the
>> group wanted. But I don't like your option 3.
>>
>> >8. Section 5.3.1: Should add the sentence "No parameterization exists for
>> >this algorithm." or similar text someplace.
>>
>> ? First sentence in the section says "...takes no explicit
>> parameters."
>
>Sorry -- I should have been more explict in saying what I wanted.  One of
>the reasons for having people actually read specs.  I would like text to the
>effect that no XML parameters are "allowed" with this algorithm identifier.

Well, if "extra" ignored parameters are not allowed for algorithms,
seems to me that that should be in the overall text for all
algorithms.

>> >9. Section 5.2.2:  See comment 6 above - recomend inclusion of -cbc in the
>> >name.

OK.

>> See response above  :-)
>>
>> >10. Section 5.2.2: ditto item 8.
>>
>> Will do but if no explicit parameters are defined for an algorithm I
>> don't see why anyone would be confused...
>>
>> >11. Section 5.3.1:  There is nothing in theory that prevents the use of RSA
>> >within an EncryptedData element, that is to encrypt the data directly.  Is
>> >this a mode that we need to /should support?
>>
>> Generally adding RSA as a sort of block encryption algorithm for
>> messages that might be large relative to the modulus would require
>> defining the padding and formatting...
>>
>> Just allowing rsa-1_5 and rsa-oaep for encrypting data which is small
>> enough to fit in place of the "key" as those algorithms are defined
>> would be easy to add as an option but I question how useful it would
>> be.
>>
>> >13.  Section 5.3.1: I suggest adding the following text. "This document
>> >RECOMMENDS that rsa-v1.5 NOT be used for transport of AES keys as there are
>> >some known attacks againist it [RSA-ATTACKS].  This document RECOMMENDS that
>> >rsa-v1.5 be used for transport of 3DES keys for compatilibity with existing
>> >cryptographic systems."  RSA-ATTACKS could either be a future document from
>> >the S/MIME group or a reference to the appropriate section in V2.
>>
>> Hummm, a NOT RECOMMENDED here seems a bit strong... How about if we just
>> say that RSA-OAEP is preferred for AES keys?
>
>I am fine with SUGGEST rather than RECOMMEND.

OK.

>> >14.  Section 5.3.2:  schema should be along the lines of:
>> >
>> ><element name="RSA-OAEP" type ="RSA-OAEPType"/>
>> ><complexType name="RSA-OAEPType">
>> >  <sequence>
>> >    <element name="DigestMethodAlgorithm" type="ds:AlgId" minOccurs="0"/>
>> >    <element name="MaskGeneratorAlgorithm" type="ds:AlgId" minOccurs="0"/>
>> >    <element name="PSourceAlgorithm" type="ds:AlgId" minOccurs="0"/>
>> >  </sequence>
>> ></complextType>
>>
>> You are quite right that the digest function parameter element shouldn't
>> be the somewhat weird OAEP I had defined. I was already going to change
>> it to <DigestMethod/> for commonality. I'm not sure if it's worth
>> having a default here.
>
>No problems with this.
>
>> >Define MaskGeneratorAlgorithm "rsa-oaep-mgf1" to be the MGF1 in RSA#1v2.0
>> >and be the default value if unspecified.
>>
>> I wanted to avoid a whole new category of algorithms. I don't see any
>> evidence of a new mask generator with noticeable
>> deployment. Permitting this adds to the complexity of implementaion...
>> (If it was added to the syntax, it should be MaskGeneratorMethod.)
>
>My label is incorrect.  I would like to see it added so that the algorithm
>does not need to be redone later if a new MG comes into effect.  I do
>however think it should be defaulted to MG1 normally.
>
>> >Define PSourceAlgorithm "rsa-oaep-pSpecified" with content base64 value.
>> >default for this algorithm is no P value specified.
>>
>> With DigestMethod being a paremeter element that could take content
>> for some hypothetical parameterized digest function, we do need a
>> separate element here.  What's wrong with just <P/>?
>
>I was just moving the ASN concepts over directly from the PKCS#1 document.
>My assumption is that they felt methods of getting P other than directly
>specified were at least possible if not probable.  This would be the only
>reason for going with a Method/algorithm rather than directly with P.
>Working group call.

Does anyone know why P is such a big deal that you might want it
calculated by an algorithm?

>> >Default for DigestMethodAlgorithm would be urn:sha-1.
>> >
>> >15.  Section 5.3.2: I suggest adding the following text: "This document
>> >RECOMMENDS that rsa-v2.0 be used for the transport of AES keys.  This
>> >document RECOMMENDS that rsa-v2.0 NOT be used for transport of 3DES keys."
>>
>> First part fine. But if someone is useing 3DES, what's wrong with
>> transporting a 3DES key with rsa-oaep?
>
>There is nothing wrong with it.  However, if we think OAEP should be use for
>3DES then I believe that v1.5 should be eleminated altogether.

I dunno. OAEP is more complex and implementations of v1.5 are
widespread...

>> >16.  Section 5.4, para 1:  "associatred" should be "associated"
>>
>> Sorry, maybe I'll actually spell check the next version...
>>
>> >17.  Section 5.4:  I don't like the implied schema for this algorithm.  I
>> >suggest something along the lines of:
>> >
>> ><complexType name="dhType">
>> >  <sequence>
>> >    <element name="OriginatorKey" type="ds:KeyValue" minOccurs="0"/>
>> >    <element name="KeyDerivationAlgorithm" type="ds:AlgId" minOccurs="0"/>
>> >    <element name="KeyWrapAlgorithm" type="ds:AlgId"/>
>> >  </sequence>
>> ></complexType>
>>
>> Why call it OriginatorKey instead of simply KeyInfo for commonality?
>
>Clarity -- I have no problems with KeyInfo.  Type should have been KeyInfo.
>
>> I'm not sure why this is a type. Algorithms are not elment nemaes but
>> attribute values. But maybe I'm confused.
>>
>> I assume by derivation algorithm you mean how to get the key from the
>> shared secret produced by the agreemnt algorithm?  As with the MGF, I
>> don't see sufficient motivation to add a new category of algorithms.
>
>Assuming you don't think the derivation algorithm will ever be shown as
>bad -- then you don't need this.
>
>> Why does it need a KeyWrap Algorthm?
>
>You still need to know how to encrypt the data with the derived key.  This
>is the key wrap algorithm.  I.e. you need someplace to specify you are using
>#kw-aes or #kw-3des.

I think that AgreementMethod occurs inside a KeyInfo which is inside
of either an EncryptedData or an EncryptedKey. I see no reason why it
should not be possible to use an agreed key dirctly for data
encryption, instead of key wrap, if you want. Anyway, the algorithm
URI comes from the Algorithm attribute of the enveloping EncryptedData
or EncryptedKey. I don't see wy it needs to be explicitly repeated
inside AgreeementMethod...

>> >18.  Add new section 5.4.3:  KeyDerivationAlgorithms. Discussion is needed
>> >on the list about the following
>> >
>> >1) do we use the CMS version (which requires ASN encoding and mapping from
>> >xml algorithm identifiers to OIDs) or do we define our own "non-standard"
>> >method of doing it.
>>
>> Obviously I think we should do our own derivation.  Otherwise we would
>> be requiring real ASN encoding. (XMLDSIG has some vestigial ASN but it
>> can all be handled with big hex constants.)
>>
>> >2) What CMS elements do we want to omit and why were they there to begin
>> >with.
>> >The elements used in CMS for key derivation are: a) ZZ (the dh-agreement
>> >value), b) Nonce, c) Algorithm ID, d) resulting key size and e) counter.
>> >The resulting key size was specifcally added to address attacks on RC2
>> >dealing with the fact that it could be both 40-bit and 128-bit.  I don't
>> >remember the specifics on the attack anymore but think it would also apply
>> >to AES with 128 or 256 bit key size.
>>
>> Currently the key size is included in the algorithm URI but I guess
>> there can be algorithms for which the key size is a parameter or
>> something so adding a key size integer to the concatenated elements
>> seems reasonable.
>>
>> >3)  What is the structure and elements for this.  I suggest> the following:
>> >
>> ><complexType name="xmlKeyDerivationType>
>> >  <sequence>
>> >    <element name="Nonce" type="ds:base64" minOccurs="0"/>
>> >    <element name="DigestMethod" type="ds:AlgId" minOccurs="0"/>
>> >    <element name="KeySize" type="integer" minOccurs="0"/>
>> >  </sequence>
>> ></complexType>
>> >
>> >KM(counter) = Hash(ZZ | <AlgURN> | counter | Nonce | KeySize)
>> >
>> >4) What is the default hash algorithm.  I recommend that we use SHA-1 for
>> >3DES iff we use the CMS encoding of the data.  Otherwise SHA-256 allows for
>> >a much better key as all bits are generated independently (rather than using
>> >the counter to "re-generate" some dependent bits).
>>
>> I don't see the coupling to CMS encoding.  As far as I'm concerned, we
>> should be avoiding ASN.1 and using string/XML encoding where we can.
>> Perhaps there should be no default and specification of a DigestMethod
>> be required.
>
>The reason that I put the coupling in is merely to say.  If we use the CMS
>encoding, lets use the CMS hash function (i.e. re-use code).  If we don't
>use the CMS encoding, SHA-256 provides better security and should be used.

I'm inclined to go with just always specifying the DigestMethod.

>> >20.  Section 5.5:  please change text from "secret" to "shared" in the first
>> >sentence.
>>
>> How about if I say "shared secret"...
>
>This is fine.
>
>> >23.  Section 5.6.1:  Should we define a new id for SHA1 or
>> use the one from
>> >the signature draft.
>>
>> Multiple ids for the same thing = bad.
>
>Yeah.
>
>>
>> >jim
>>
>> Thanks,
>> Donald
>>
>
>jim

Thanks,
Donald

Received on Thursday, 7 June 2001 09:44:39 UTC