Re: (Another) new ID of potential interest

I can easily understand how these things slip out.  I needed to find the
document in order to figure out what I was thinking of when I wrote some of
this.

Some comments in-line


> -----Original Message-----
> From: Herzog, Jonathan - 0668 - MITLL [mailto:[email protected]]
> Sent: Tuesday, August 03, 2010 11:48 AM
> To: Jim Schaad
> Cc: Khazan, Roger - 0668 - MITLL; [email protected]
> Subject: Re: [smime] (Another) new ID of potential interest
> 
> 
> Oh, goodness. Have I really let this lie, unanswered, for almost four
> months? Yes, yes I have. My apologies. In any case, let me reply to
> your concerns:
> 
> On Apr 10, 2010, at 8:31 PM, Jim Schaad wrote:
> 
> > Gentlemen,
> >
> > I have been reviewing this document I would like to suggest that it
> is
> > either overgenerous in the set of cryptographic services that are
> provided
> > or missing some pre-conditions that are necessary in order to obtain
> those
> > services.
> >
> > In section 1 states that one of the services that is available is
> > sender-authentication, however no restrictions are placed on when
> this
> > service is available anyplace in the document that I can find.  I
> would like
> > to suggest that is this not actually either a very strong service or
> one
> > that is always available.
> >
> > Please consider the following sequence of actions:
> >
> > 1.  Alice sends a static-static Authenticated message to both Bob and
> > Mallory.  Alice will use a static-static DH method to transport the
> key to
> > Bob, it does not really matter what technique is use to transport the
> key to
> > Mallory.  The important thing is just that this is one message and
> thus one
> > authentication key.
> >
> > 2.  Mallory intercepts the message and prevents Bob from receiving
> it.
> >
> > 3.  Mallory creates a new message using the same authentication key
> that
> > Alice generated to authenticate a new message.  Mallory may or may
> not
> > include himself as a recipient of the message.
> >
> > 4.  Mallory sends the new message to Bob.
> >
> > 5.  Bob receives the message, validates the static-static DH works
> and
> > authenticates the message.  Bob now believes that Alice was the
> original
> > sender of the message.
> >
> > There is a difference in services one gets between an online protocol
> and a
> > store-and-forward protocol.  For on-line you only ever get a pair-
> wise
> > operation and you have the immediate check that the negotiation was
> > successful.  This is lacking for the store-and-forward versions.
> >
> > This difference is only relevant if you are looking for
> > sender-authentication of the messages that are sent.  Thus there are
> never
> > an issue for an ephemeral-static version of the protocols.  Mallory
> could
> > run the same sequence as above, but since there is no reason for Bob
> to
> > believe that Alice sent the message, there is not a strong attack.
> 
> This is entirely correct, and an embarrassing oversight on our part.
> Your attack works entirely as advertised, and it is incorrect for us to
> claim that our proposal provides 'sender authentication.'
> 
> 
> > In order to get a sender-authentication of a message one needs to do
> the
> > following:
> >
> > 1.  Mandate in any protocol using this that only a single Recipient
> Info can
> > ever occur in a message.
> >
> > 2.  Mandate that the ukm be present in the message and,
> >
> > 3.  Mandate that a timeliness element be included in the ukm.
> >
> > In any event, the sender-authentication can never be taking to a
> third party
> > for verification since either party could have constructed the
> message.  Bob
> > in fact could construct a message despite the fact that Alice has
> never sent
> > a message to Bob.
> 
> Those are all good suggestions, but I think that we will take another
> approach entirely: dropping the claim of sender authentication. Sender
> authentication, was never our goal, actually. Rather, our goal was to
> provide a way for the message-sender to use a certified elliptic-curve
> Diffie-Hellman key. If we get that but not sender authentication, well,
> then so be it.
> 
> Therefore, we propose the following changes:
> 
> * Change the abstract to:
> 
>   "This document describes how to use 'static-static' Elliptic Curve
>    Diffie-Hellman key-agreement with the Cryptographic Message Syntax.
>    In this form of key-agreement, the Diffie-Hellman values of both
>    sender and receiver are long-term values contained in certificates."
> 
> * In section 1 (at the end), we change:
> 
> 
>    We note that like ephemeral-static ECDH, static-static ECDH creates
> a
>    secret key shared by sender and receiver.  Unlike ephemeral-static
>    ECDH, however, static-static ECDH uses a static key pair for the
>    sender and therefore allows for the verification of the sender's
>    identity.  Each of the three CMS structures discussed in this
>    document (EnvelopedData, AuthenticatedData, and AuthEnvelopedData)
>    use these properties of static-static ECDH to achieve different
>    goals:
> 
>    o  EnvelopedData uses static-static ECDH to provide data
>       confidentiality.  It will not necessarily, however, provide
> either
>       sender-authentication or data integrity.
> 
>    o  AuthenticatedData uses static-static ECDH to provide sender-
>       authentication and data-integrity.  It will not necessarily,
>       however, provide confidentiality for the data.
> 
>    o  AuthEnvelopedData uses static-static ECDH to provide all of
>       confidentiality, sender-authentication, and data-integrity.
> 
> to
> 
> 
> 
>    We note that like ephemeral-static ECDH, static-static ECDH creates
> a
>    secret key shared by sender and receiver.  Unlike ephemeral-static
>    ECDH, however, static-static ECDH uses a static key pair for the
>    sender.  Each of the three CMS structures discussed in this
>    document (EnvelopedData, AuthenticatedData, and AuthEnvelopedData)
>    use static-static ECDH to achieve different goals:
> 
>    o  EnvelopedData uses static-static ECDH to provide data
>       confidentiality.  It will not necessarily, however, provide data
>       integrity.
> 
>    o  AuthenticatedData uses static-static ECDH to provide
>       data-integrity.  It will not necessarily,
>       however, provide confidentiality for the data.

It will not provide confidentiality for the data.  I would suggest removal
or amendment of the second sentence.

> 
>    o  AuthEnvelopedData uses static-static ECDH to provide both of
>       confidentiality and data-integrity.
> 
> * In Section 5, we change
> 
>    AuthenticatedData or AuthEnvelopedData messages, on the other hand,
>    are not given any form of ECDH by [CMS-ECC].  This is appropriate:
> it
>    defines only ephemeral-static Diffie-Hellman, and this form of
>    Diffie-Hellman does not (inherently) provide any form of sender-
>    authentication.  This document, on the other hand, requires that the
>    sender use a certified public value.  Thus, this form of key-
>    agreement provides implicit key authentication and, therefore,
>    authentication of the sender.
> 
> to
> 
>    AuthenticatedData or AuthEnvelopedData messages, on the other hand,
>    are not given any form of ECDH by [CMS-ECC].  This is appropriate:
> it
>    defines only ephemeral-static Diffie-Hellman, and this form of
>    Diffie-Hellman does not (inherently) provide any form of data-origin
>    authentication.  This document, on the other hand, requires that the
>    sender use a certified public value.  Thus, this form of key-
>    agreement provides implicit key authentication and, under some
>    circumstances, data-origin authentication. (See Section 7.)
> 
> 
> * In Section 7, we describe the attack you provide above. (Do you mind
> if I use your text as a starting point?) We then explain that data-
> origin cannot be guaranteed unless it is a priori guaranteed that the
> message be sent by the sender to exactly one recipient. And if that's
> not the case, data-origin must be provided by some other mechanism
> (such as digital signatures.)
> 

You can steal the text wholesale for all I care.

> 
> 
> 
> > Other comments:
> >
> > 1.  As written the ukm descriptions are incorrect.  For section 2.1 -
> the
> > correct order is.  If ukm is present, it contains the ECC-CMS-
> SharedInfo
> > structure.  If the user wants to add a random value, it is placed in
> the
> > entityUInfo field of this structure.
> 
> I don't quite understand. RFC 5652 defines ukm as being a
> UserKeyingMaterial, which is then defined to be an OCTET STRING. What
> do you mean, then, when you say that ukm contains a structure?
> 
> BTW, the text in our draft, as submitted, mirrors the analogous section
> from RFC 5753:
> 
>        ...The ukm is
>       placed in the entityUInfo field of the ECC-CMS-SharedInfo
>       structure.  When present, the ukm is used to ensure that a
>       different key-encryption key is generated, even when the
> ephemeral
>       private key is improperly used more than once, by using the ECC-
>       CMS-SharedInfo as an input to the key derivation function...
> 

You are correct - that is the way it is written.  I need to find some really
old code to find out if it is written correctly or if there is a problem in
how it is done.  For now please ignore this comment.

> 
> 
> > 2.  The bullet list in section 2.2. lists the ukm twice.  (The first
> bullet
> > here is vastly confusing - perhaps a error in doing updates?
> 
> Oops. Yes, this was a minor edit gone wrong. The list should read:
> 
> 
>    o  an integer "keydatalen", which is
>       the KeyWrapAlgorithm symmetric key-size in bits, and
> 
>    o  the value of ukm, if used.
> 
> 
> > 3.  Note 3278bis appears to have been published in January of this
> year, so
> > saying that the update is a work in progress appears to be
> significantly out
> > of date.
> 
> Thanks. We can actually remove the whole comment, since it is now moot.
> 
> > 4.  Several references to section 5 appear to be out of date.
> 
> Thanks. Will fix.
> 
> > 5.  You need to supply an ASN.1 module.  I have a personal preference
> to one
> > that uses the new ASN.1 but could live with an 88 module if
> necessary.
> > Doing so might expose some deficiencies in the document.
> 
> Do you really think so? We don't define any new ASN.1 structures or
> values. But if you do think that we need to provide an ASN.1 module,
> then please help me understand what you envision. What would this
> module contain that's not already in other modules, such as the one in
> Section 12.1 of RFC 5652?

Sorry - I thought that I had seen some OIDs defined by this document - but
they appear to have been defined in RFC 5753 so no you do not need a module.

> 
> > 6.  You need to look at the document before it is published.  Having
> the
> > document tin twice is somewhat crazy.
> 
> I'm sorry, but what is the 'document tin'?

Sorry - if you look at the document on line, then there are two copies of
the document in the .txt file.

> 
> Thanks again for your help.
> 
> --
> Jonathan Herzog
voice:  (781)
> 981-2356
> Technical Staff							fax:
(781)
> 981-7687
> Cyber Systems and Technology Group		email:  [email protected]
> MIT Lincoln Laboratory               			www:
> http://www.ll.mit.edu/CST/
> 244 Wood Street
> Lexington, MA 02420-9185


_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime