RE: Comments on draft-ietf-smime-3278bis-01.txt

["Jim Schaad" <ietf@xxxxxxxxxxxxxxxxx>]

Sean,

I have removed items that I considered to be completed

Jim


> -----Original Message-----
> From: owner-ietf-smime@xxxxxxxxxxxx [mailto:owner-ietf-
> smime@xxxxxxxxxxxx] On Behalf Of Turner, Sean P.
> Sent: Thursday, August 21, 2008 6:10 PM
> To: 'Jim Schaad'; ietf-smime@xxxxxxx
> Subject: RE: Comments on draft-ietf-smime-3278bis-01.txt
> 
> 
> Jim,
> 
> Responses inline... Still working on 3 of the comments, which have been
> moved to the bottom of the email.
> 
> All,
> 
> Jim's raised some concerns about the parameters fields and whether they
> should be NULL or ABSENT.  Additionally, this draft doesn't discuss
> hash
> algorithm's parameter fields.  We've got two options:
> 
> 1) We leave the text as is and include some wording similar to what we
> say
> about hash algorithm parameters (must support both NULL and absent
> parameters and SHOULD generate absent). Note we need to add this text
> regardless for the hash algorithm parameters because right now the ID
> says
> nothing about them.
>

The major problem I have this text as it stands, is that the associated of
OID and ASN.1 type becomes different for when it appears in an originator
key vs when it appears in a public key (i.e. certificate).  In theory, there
should actually not be a problem with having the full domain parameters
appear in the originator key field, although the reciver should check that
the parameters match those used for their key.
 
> 2) We poll implementers. We'd need to ask those that implemented:
> 
> - The originatorKey algorithm field MUST contain the id-ecPublicKey
> object
> identifier when implementing ES ECDH with EnvelopedData but is the
> parameter
> field populated with a NULL or is it ABSENT (i.e., the originatorKey is
> a
> SEQUENCE of one component, the OID id-ecPublicKey).
> 
> - The signatureAlgorithm algorithm field MUST contain the ecdsa-with-*
> object identifier when implementing ECDSA with SignedData but is the
> parameter field populated with a NULL or is it ABSENT (i.e., the
> signatureAlgorithm is a SEQUENCE of one component, the OID ecdsa-with-
> *).
> 
> In the past, we've solve this problem with the weasel wording for hash
> algorithm parameters, but do we want to continue along this path? Is
> there a
> widely deployed base of ES ECDH with EnvelopedData and did anybody do
> something different than what RFC5008 says for ECDSA (i.e., absent
> parameters when you use ecdsa-with-sha*)?
> 
> spt
> 
> >-----Original Message-----
> >From: owner-ietf-smime@xxxxxxxxxxxx
> >[mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Jim Schaad
> >Sent: Thursday, August 14, 2008 9:01 AM
> >To: Sean P. Turner
> >Cc: Ietf-Smime
> >Subject: Comments on draft-ietf-smime-3278bis-01.txt
> >
> >


> >Section 3. - Is it permitted to do ECC static-static?
> 
> I believe it's permitted, but nobody asked for it so the RFC3278
> authors
> didn't include it.  Since ES DH was the MUST I assume they went with ES
> ECDH. Do you want to add it?

We did allow for static-static DH, analogy says we might want to include it.
The question would be 1) would it be used (probably not) and 2) is there a
community that might thing you should validate the senders certificate prior
to decrypting a message (there were such communities, I think they have been
sufficiently discouraged from the practice).

I think a simple sentence -- Static-Static is not covered in this document,
the MQV method provides for better security, if you want to use ECSS - it is
analogous.  (clean up the language).

> 
> >Section 3.1.1 - originator - The parameters SHOULD be ABSENT
> >not NULL.  This is 1) consistent with what is done for DH and
> >2) means that you don't have one more additional encoding
> >binding for the originator field as oppose to the parameters
> 
> I think we should be doing what DH does and just have absent
> parameters.

Issue open

> 
> >Section 3.1.1 - please justify the requirement for DER
> >encoding of ECPoint.
> 
> I assume there isn't one and this was a cut-and-paste from the other
> field.
> We'd just drop the DER part and the sentence would read as follows:
> "The
> originatorKey publicKey field MUST contain the value of the ASN.1 type
> ECPoint (see Section 8.2), which represents the sending agent's
> ephemeral EC
> public key."

????

> 
> >Section 3.1.1 - what about the ukm field?
> 
> The "but with the following restrictions:" before the bullets leads me
> to
> believe there are no restrictions on the other 3 fields.  I assume
> you're
> asking for more text and we could add a blurb about ukm being absent.
> If we
> add something about ukm we may just add something about the other
> fields and
> change the intro sentence.

Text needs to be included as to what goes into the UKM field  - specifically
it also needs to say where and how to use the ukm material in the (I assume)
ECC-CMS-SharedInfo structure to be used during key derivation.

> 
> >Section 3.2 - I don't understand why ES ECDH cannot be used
> >for AuthenticatedData.  We can use the DH algorithm with it.
> >I can understand if you want to state that some ADDITIONAL
> >security properties exist from using 1-pass ECMQV.
> 
> I dug through the mail archives and found a thread between Francois
> Rousseau, Dan Brown, and Simon Blake Wilson in March 2001.  Before we
> add
> it, I think we'd need to address the points raised.  Here's how it
> went:
> ---
> a. Sections 1, 3.2, 4.1 and 8.2, it is not clear why only the ECMQV key
> agreement algorithm is supported with AuthenticatedData and not also
> the
> ECDH key agreement algorithm. Although ECMQV is comparable to KEA,
> which can
> also be used with AuthenticatedData, ECDH is the analog to the X9.42
> Diffie-Hellman key agreement algorithm specified in RFC 2630 and is the
> default algorithm with AuthenticatedData.
> 
> --> We looked at RFC 2630 which specifies the use of ephemeral-static
> Diffie-Hellman within AuthenticatedData---but we didn't understand how
> this
> mechanism provides authentication of the sender since the sender is not
> certified. We didn't want to include the analogous technique based on
> these
> concerns.

This is the key issue - Authenticated data DOES NOT provide data origination
assurance.  All it says is that the data was not modified during "transit".
It does not say that the data is the same as the original sender.

> 
> FR> However, as indicated in Section 4 of your ID, AuthenticatedData
> lacks
> non-repudiation, and so in some instances is preferable to SignedData
> (For
> example, the sending agent may not want the message to be authenticated
> when
> forwarded). Using ephemeral-static ECDH within AuthenticatedData can
> achieve
> this goal, but not necessarily ECMQV or static-static ECDH, which both
> require a certified public key from the sender. As per Section 9 of RFC
> 2630, the goal of AuthenticatedData is to protect the integrity of the
> content, but not to necessarily provide authentication of the sender.
> Note
> also that RFC 2631 specifies both the ephemeral-static and the static-
> static
> Diffie-Hellman modes.
> 
> --> Of course we could have included static-static ECDH, but this would
> involve a fixed Diffie-Hellman "shared secret" (Z) between each pair of
> correspondents, which seems undesirable.
> 
> FR> True, but I though this was the reason under Section 8.2 of your ID
> that
> the octet string ukm in the entityUInfo field of the ECC-CMS-SharedInfo
> could optionally be supplied by the sending agent. By mandating the use
> of
> the octet string ukm with the static-static ECDH, you would certainly
> avoid
> this undesirable effect. Similarly, in Section 2.1.2 of RFC 2631, the
> partyAInfo MUST be used in Static-Static mode, but MAY appear in
> Ephemeral-Static mode to avoid this same undesirable effect.
> 
> --> Make sense? Can anyone explain how ephemeral-static Diffie-Hellman
> provides security with AuthenticatedData?
> 
> FR> I do not consider myself an expert with AuthenticatedData, but see
> my
> two responses above.
> ---
> >Section 3.2.1 - for the bullet ukm - the last sentence makes
> >no sense--- Part of the problem is that the next paragraph is
> >not further indented.
> 
> This was typo. The paragraph after it should have been connected to the
> ukm
> paragraph.
> 
> >Section 3.2.1 - I would recommend for algorithm that absent
> >rather than NULL be used to simplify encoding/decoding steps
> 
> See intro.
> 
> >Section 3.2.2 - what are the domain parameters the same as?
> 
> The check is that the recipient's domain parameters and the sender's
> domain
> parameters are the same. Will add ", as the sender's domain parameters"
> to
> the end of that sentence.
> 
> >Section 3.2.3 - where does the additional ukm come from  It
> >is/is not an ouptut of the key deployment/agreement algorithm?
> 
> The sentence was missing something from 3278. It should read: "The
> receiving
> agent then retrieves the static and ephemeral EC public keys of the
> originator, from the originator and ukm fields [as described in Section
> 3.2.1, and its static EC public key identified in the rid] field and
> checks
> that the domain parameters are the same."  Does this clear things up?
> 
> >Section 3.2.3 - Are there requirements/recommendations for
> >validating a sender's certificate?  Are there security
> >implications for not doing so?
> 
> I think we could add something about validating the certificate prior
> to
> use.  We've been discussing something similar for the S/MIME v3.2 IDs.
> I'll
> add a reference to the security considerations and will grab the text
> from
> MSGbis.
> 

This is a problem of what AuthenticatedData provides vs what they think it
provides - see above comment.


> >Section 5 - Are the KDF functions referenced here defined
> >using an object identifier in the X9.62 specifications?  If so
> >it would be good to include those OIDs in the ASN.1 module.
> >(No private opinion)
> 
> Yes they use the OIDs from X9.62 and they are included in the modules.

I don't see any identifier for sha1kdf (or what I would consider and
equivalent).  There are ones for the entire scheme, but not for this piece
of the scheme.


> 
> >Section 8.1 - Has the following text:
> >   When the object identifier id-ecPublicKey is used here with an
> >   algorithm identifier, the associated parameters contain NULL.
> >
> >   I thought that there were ec domain parameters that were to
> >be encoded with the public key.  Where else would this be
> >used?  Is this from the OriginatorKey clause above that I
> >think is incorrect?
> 
> In this ID it's only used in the OriginatorKey clause.  I'd change the
> following "The following object identifier is used in this document to
> indicate an elliptic curve public key:" to "The following object
> identifier
> is used in this document to indicate an elliptic curve public key in
> the
> OriginatorKey field:" and change "When the object identifier id-
> ecPublicKey
> is used here with an algorithm identifier, the associated parameters
> contain
> NULL" to "When the object identifier id-ecPublicKey is used here with
> an
> algorithm identifier, the associated parameters contain are absent."

Result may be modified by discussion from top of mail message

> 
> >Section 8.1 - for ecdas-with-*, is it considered acceptable to
> >have absent parameters?
> 
> See intro.
> 

Open


> >Section 8.1 - The parameters for the encryption schemes -
> >        KeyWrap ::= OBJECT IDENTIFIER or
> >        KeyWrap ::= AlgorithmIdentifier
> >        It is not clear from the text at the end of the last
> >paragraph in this section.  Many people use OID and "algorithm
> >identifier" as the same thing.
> 
> How about: When the object identifiers are used here within an
> algorithm
> identifier, the associated parameters field contains the
> KeyWrapAlgorithm
> field, which indicates the key wrap algorithm and any assoicated
> parameters.

Combined with a clarification in the ASN.1 - this should be fine

> 
> >Section 8.2  What happens for keyInfo if the key wrap
> >algorithm actually has parameters?
> 
> I think this is wrong.  It ought to allow for parameters and absent
> parameters (i.e., for aes*-wrap).  I propose:
> Old: keyInfo contains the object identifier of the key-encryption
> algorithm
> (used to wrap the CEK) and NULL parameters.
> New: keyInfo contains the object identifier of the key-encryption
> algorithm
> (used to wrap the CEK) and associated parameters. In this
> specification,
> 3DES wrap has NULL parameters while the AES wraps have absent
> parameters.

Fine

> > 
> Still working on these:
> 
> >Section 3.2.2 - Please elaborate on the re-used statement in
> >the last paragraph.  Can be re-used for what?  for how long?
> >why can't it be re-used for encrypted data?
> >
> >Section 3.2.2 - if you re-use the ephemeral - what does/does
> >not need to be changed?  The additional ukm?
> 
> I'm leaning towards deleting this sentnece and the similar sentences in
> 4.1.2 and 4.2.2.
> 
> >Section 4.1.2 - Note:  There is a legal attack where by the
> >recipient modifies the content and goes to court with the
> >modified content.  Unless you bind the output MAC in with the
> >MAC key, you cannot prevent this type of attack.
> 
> Not sure what to do with this one.

This is part and parcel of the question of what AuthenticatedData does or
does not provide as a security service.  Fix that concept and this goes
away.

Jim