Re: Last Call: <draft-herzog-static-ecdh-04.txt> (Use of static-static E


On Mar 3, 2011, at 12:37 PM, Russ Housley wrote:



Begin forwarded message:

From: Rene Struik <rstruik(_dot_)ext(_at_)gmail(_dot_)com>
Date: March 2, 2011 10:03:33 PM EST
To: ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call: <draft-herzog-static-ecdh-04.txt> (Use of 
static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic 
Message Syntax) to Informational RFC

Dear colleagues:
Please find below my (modest) comments on draft-herzog-static-ecdh-05 (an 
update of the document that occurred since the moment 
of issuing the LC).


Thanks for the comments. I've read through them, and plan to incorporate them 
into a -06 version in the next few days. Before I do, however, do you mind if I 
explain what I did and ask a few questions?

I. Editorial comments:

(E-a) p. 1, Disclaimer, l. 3: "conclusions and" should read "conclusions, 
and".


I don't disagree, but the Disclaimer is a magic incantation we need to include 
verbatim in each of our documents. I cannot change it without invoking the 
wrath of our legal department, so I hope you'll kindly look the other way it if 
I leave it the way it is?

(E-b) p. 11, Clause 7, l. -2: "Consder" should read "Consider".
(E-c) p. 12, Clause 7, last para before two bullet points, l. 3: "reciever" 
should read "receiver".


Whoops. Thanks for catching these.

(E-d) p. 13, Clause 10.2, l. -3: The paper by Menezes and Ustaoglu has 
appeared in International Journal of Applied Cryptography, 
Vol. 2, No. 2, pp. 154-158, 2010.


That's great news. Thanks for mentioning this. (Reference updated.)

(E-e) p. 4, l. -5: The motivation for specifying ECDH seems to be not so 
much that ECMQV is around (but having problems, as you stated), 
but that static-static-ECDH is *not* 
around. Thus, specifying static-static-ECDH adds more options to the 
solution space.


I'm not sure how to interpret this. Is this just a general comment, or are you 
suggesting some change to the draft? if the later, can you say a little more 
about the change you would like to see?

II. Technical comments:

(T-f) p. 5, Clause 1, forelast bullet: The term "data integrity" is more 
aptly called "data authenticity" (and would also align well with 
AuthenticatedData CMS structure called out at the beginning of the same 
sentence).


We will change 'Data integrity' to 'data authenticity'.

NOTE - I am aware of the "attack in Clause 7, but this 
attack seems to be more a flaw in the original CMS scheme, since effective 
irrespective of the key agreement method (i.e., not just static-
static-ECDH): A --> B: E_K(k) || Secured_k(m) allows any entity C who 
obtains the same key k to replace Secured_k(m) by another valid 
string. This suggests that (1) one should call this out in the text; (2) one 
should fix the original problem with CMS (e.g., tieing k to K, the
originator, or recipient via, e.g., a one-way function.


I can call it out in the text, and will do so, but fixing the problem in CMS is 
a little beyond the scope of this Draft. We hope to address it a separate Draft 
(forthcoming).

(T-g) p. 6, Clause 2.2, l. -5: At first, it is suggested that the sending 
agent obtains the recipient's public key somehow (e.g., from its 
certificate), thus suggesting that certificates are not the only option by 
which the public key may be obtained. However, later on it is stated 
that "it confirms that both certificates [...]", thus suggesting that each 
of the parties involved in this message flow have public keys that
are certified and that only those can be used. This is confusing.


The intention is that both sender and receiver must have certified public keys. 
From the abstract:

   In this form of key-agreement, the Diffie-Hellman values of both
   sender and receiver are long-term values contained in certificates.

Also, the fact that both sender and receiver must have certificates is implicit 
in Section 2.1:

   o  originator identifies the static EC public key of the sender.  It
      MUST be either issuerAndSerialNumber or subjectKeyIdentifier, and
      point to one of the sending agent's certificates.

...

   o  recipientEncryptedKeys contains an identifier and an encrypted CEK
      for each recipient.  The RecipientEncryptedKey
      KeyAgreeRecipientIdentifier MUST contain either the
      issuerAndSerialNumber identifying the recipient's certificate or
      the RecipientKeyIdentifier containing the subject key identifier
      from the recipient's certificate.

But you are right: the use of 'e.g.' is a bit confusing. To resolve this 
confusion, I propose to change Section 2.2 from

   When using static-static ECDH with EnvelopedData, the sending agent
   first obtains the recipient's EC public key and domain parameters
   (e.g. from the recipient's certificate). 

to
 
          When using static-static ECDH with EnvelopedData, the
          sending agent first obtains the EC public key(s) and domain
          parameters contained in the recipient's certificate.

and Section 2.3 from 

   The receiver then retrieves the static EC public key identified in
   the rid field.

to

          The receiver then retrieves the sender's certificate
          identified in the rid field.

Do you think that these two changes would resolve the confusion?

(T-h) p. 6, Clause 2.2, l. -6 ff: Given the lack of shall/should/may 
language, it is unclear whether one stipulates that one
checks that public keys in the certificate are on a specific curve (i.e., 
one does public key validation) or something more relaxed (such as checking
that the claimed elliptic curve domain parameters are the same, without 
checking the public keys themselves. The para would benefit from some 
firmed-up language here. This should also clarify whether one, in fact, 
checks the validity of the certificate that included the public key



Good points. The language of this draft was based on that in Section 3.1.2 of 
RFC 3278, but it could be firmed up. 

With regard to parameter validation, SEC1 (Section 3.2.2) lists a few methods 
by which a public-key can be checked for valid parameters:

* Full check,
* Partial check, and
* Trust the CA. 

(I'm paraphrasing a bit.) Since RFC 5480 doesn't provide any way for the CA to 
mark the parameters as 'checked' or 'not checked', I'll have our Draft say that 
the sender and receiver:

* SHOULD do a full parameter check for standard ECDH, and
* SHOULD do a full check for co-factor ECDH, or failing that, SHOULD do a 
partial check (as seems to be permitted in SEC1, Section 3.2.3).

(By the way, do you know if these validation checks exist in a RFC anywhere? I 
couldn't find them in RFC 6090...)

As for certificate validation: I'd prefer to remain silent on the issue. That 
is, I'd prefer to focus entirely on how to use the values found in the 
certificate. Issues regarding when, how often, and how to validate the 
certificate seem like much larger issues and out of scope. Thoughts?



But given the above, I've changed the language as follows:

Was:

   When using static-static ECDH with EnvelopedData, the sending agent...
   confirms that both
   certificates contain public-key values with the same curve
   parameters, and that both of these public-key values are marked as
   appropriate for ECDH (that is, marked with algorithm-identifiers id-
   ecPublicKey or id-ecDH [PKI-ECC]).  The sender then determines:

   o  whether to use standard or cofactor Diffie-Hellman, and

   o  which hash algorithms to use for the key-derivation function...


IS NOW


   When using static-static ECDH with EnvelopedData, the sending agent...  
   MUST confirm the following at least
   once per recipient-certificate:

   o  That both certificates (the recipient's certificate and its own)
      contain public-key values with the same curve parameters, and

   o  That both of these public-key values are marked as appropriate for
      ECDH (that is, marked with algorithm-identifiers id-ecPublicKey or
      id-ecDH [RFC5480]).

   The sender then determines whether to use standard or cofactor
   Diffie-Hellman.  After doing so, the sender SHOULD validate the
   receiver's public-key parameters at least once per public key:

   o  If standard Diffie-Hellman is to be used, the sender SHOULD use
      the Elliptic Curve Public Key Validation Primitive found in
      Section 3.2.2.1 of [SEC1].

   o  If cofactor Diffie-Hellman is to be used, the sender SHOULD use
      the Elliptic Curve Public Key Validation Primitive found in
      Section 3.2.2.1 of [SEC1].  If the sender chooses not to apply
      this primitive (for performance reasons, perhaps) then it SHOULD
      apply the Elliptic Curve Public Key Partial Validation Primitive
      found in Section 3.2.3.1 of [SEC1].

   The sender then determines which hash algorithms to use for the key-
   derivation function...

(T-i) p. 7, Clause 2.3, l. 8 ff: same comment as T-h, but now for 
recipient's side.


WAS:

   When using static-static ECDH with EnvelopedData, the receiving agent
   retrieves keyEncryptionAlgorithm to determine the key-agreement
   algorithm chosen by the sender, which will identify:

   o  the domain-parameters of the curve used,

   o  whether standard or cofactor Diffie-Hellman was used, and

   o  which hash-function was used for the KDF.

   The receiver then retrieves the static EC public key identified in
   the rid field.  It confirms that both certificates contain public-key
   values associated with the curve identified by the
   keyEncryptionAlgorithm, and that both of these public-key values are
   marked as appropriate for ECDH (that is, marked with algorithm-
   identifiers id-ecPublicKey or id-ecDH [PKI-ECC]).  The receiver then
   determines a bit string "SharedInfo", which is the DER encoding of
   ECC-CMS-SharedInfo (see Section 7.2 of [CMS-ECC]) and performs the
   key agreement operation of the Elliptic Curve Diffie-Hellman Scheme
   specified in [SEC1]; in either case, use the KDF defined in Section
   3.6.1 of [SEC1].  As a result, the receiving agent obtains a shared
   secret bit string "K", which it uses as the pairwise key-encryption
   key to unwrap the CEK.


IS NOW:


   When using static-static ECDH with EnvelopedData, the receiving agent
   retrieves keyEncryptionAlgorithm to determine the key-agreement
   algorithm chosen by the sender, which will identify:

   o  the domain-parameters of the curve used,

   o  whether standard or cofactor Diffie-Hellman was used, and

   o  which hash-function was used for the KDF.

   The receiver then retrieves the sender's certificate identified in
   the rid field.  It MUST confirm the following at least once per
   sender-certificate:

   o  That both certificates (the sender's certificate and its own)
      contain public-key values with the same curve parameters, and

   o  That both of these public-key values are marked as appropriate for
      ECDH (that is, marked with algorithm-identifiers id-ecPublicKey or
      id-ecDH [RFC5480]).

   The receiver then determines whether standard or cofactor Diffie-
   Hellman was used.  After doing so, the receiver SHOULD validate the
   sender's public-key paramaters at least once per public key:

   o  If standard Diffie-Hellman is to be used: The receiver SHOULD use
      the Elliptic Curve Public Key Validation Primitive found in
      Section 3.2.2.1 of [SEC1].

   o  If cofactor Diffie-Hellman is to be used: The receiver SHOULD use
      the Elliptic Curve Public Key Validation Primitive found in
      Section 3.2.2.1 of [SEC1].  If the receiver chooses not to apply
      this primitive (for performance reasons, perhaps) then it SHOULD
      apply the Elliptic Curve Public Key Partial Validation Primitive
      found in Section 3.2.3.1 of [SEC1].

   The receiver then determines a bit string "SharedInfo", which is the
   DER encoding of ECC-CMS-SharedInfo (see Section 7.2 of [RFC5753]) and
   performs the key agreement operation of the Elliptic Curve Diffie-
   Hellman Scheme specified in [SEC1]; in either case, use the KDF
   defined in Section 3.6.1 of [SEC1].  As a result, the receiving agent
   obtains a shared secret bit string "K", which it uses as the pairwise
   key-encryption key to unwrap the CEK.

(T-j) p. 11, Clause 6, l. 4 (also l. 16): I was hoping that by now (2011), 
the unkeyed hash function SHA-1 would be moth-balled (rather than 
reintroducing this option), more than 5 years after more serious SHA-1 
attacks were presented in the academic community.


Fair enough. Shall I say that implementations SHOULD NOT support the SHA-1 
schemes?

Along those same lines, I will also change the DES algorithms to SHOULD NOT.

(T-k) p. 11, Clause 6, l. 3 (also l. 15): Why not introduce the CTR 
encryption mode as an option, at least when authenticity is provided? 
After all, CTR mode allows implementation of block-ciphers with just the 
forward encryption mode and offers parallelization and precomputation 
prospects.


I left it out because I have serious reservations about the security of counter 
mode. But in looking in to your question, I see there's an even-more serious 
problem: I can't find an RFC for AES-in-counter-mode for CMS. Perhaps, though, 
my Google-foo is insufficient. Do you have a pointer to an appropriate RFC?

(But your question did spur me to add AES in CCM and GCM as optional 
algorithms.)

(T-l) General: When static-static ECDH, as specified here, stipulates 
checking of the certificate including the public key and that certificate is
an ECDSA certificate, significant speed-ups of the computations are possible 
by combining the key computation step and ECDSA signature verification
-- cf. 
http://www.ietf.org/proceedings/78/slides/saag-7.pdf.
 or the SAC 2010 paper referenced in that IETF-78 presentation. These 
results also apply here
(and can obviously be ignored or embraced depending upon implementation). I 
would suggest adding a one-line statement that if ECDSA is used, one shall 
use the "friendly ECDSA" scheme as in the IETF-78 presentation (which has 
the same format as the ordinary one).



That seems like an impressive speed-up, but is this really the right document 
for the SHALL you recommend? If I read your mail correctly (which I admit may 
not be the case) it sounds like your proposed SHALL is binding on the CA which 
issued either the sender's certificate or the receiver's certificate. If this 
is the case, I worry that it would be out of place in this draft, which (as 
written now) only becomes relevant after certificates are issued.

Or am I reading this incorrectly?

Thanks.


-- 
Jonathan Herzog                                                 voice:  (781) 
981-2356
Technical Staff                                                 fax:    (781) 
981-7687
Cyber Systems and Technology Group              email:  
jherzog(_at_)ll(_dot_)mit(_dot_)edu
MIT Lincoln Laboratory                                  www:    
http://www.ll.mit.edu/CST/
244 Wood Street    
Lexington, MA 02420-9185

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: <draft-herzog-static-ecdh-04.txt> (Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax) to Informational RFC