ietf
[Top] [All Lists]

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

2011-03-14 09:32:11
Dear Jonathan:

Thanks for our phone call yesterday afternoon (Thu March 10th) and your
summary below.

Please see my further comments below on your feedback on my review
comments (T-h), (T-i), (T-k), and (T-l),
a) where you labelled (T-h) and (T-i) as "overtaken by events";
b) where (T-k) refers to CTR mode;
c) where (T-l) refers to speed-up support.

I have some security concerns re #a, a question re #b, and a remark re
#c. If lack of time, at least try and address the security concerns.

Please feel free to discuss.

Have a nice weekend (well, it probably already started).

Best regards, Rene


On 10/03/2011 5:50 PM, Herzog, Jonathan - 0668 - MITLL wrote:
Just to keep everyone informed: Dr. Struik and I spoke by phone earlier today 
about his comments. My recollection of the conversation is that he accepted 
most of the comments as resolved, modulo the following additional details:

(And Dr. Struik! One of our agreements has been overtaken by events! Please 
see below.)


On Mar 7, 2011, at 1:51 PM, Herzog, Jonathan - 0668 - MITLL wrote:

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

(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?
This comment got folded into another comment about our motivation. The new 
version dispenses with motivations (1) and (3), focusing on the fact that 
ECMQV is no longer in Suite B. Therefore, some participants will not be able 
to use ECMQV for policy reasons, and may also be unable to sign their 
messages for lack of a certified signature key. This Draft presents 
static-static ECDH as an alternative mechanism for achieving source 
authentication if they should happen to have a certified ECDH key.




(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.
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.

This last sentence now reads:

   The receiver then retrieves the sender's certificate identified in
   the rid field, and extracts the EC public key(s) and domain
   parameters contained therein. 



(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).

***** Dr. Struik! This has been overtaken by events! ************

Due to IPR concerns, I have removed these checks from the draft. The relevant 
sections now read:

Section 2.2:

   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.  It 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]).

RS>>
[First a disclaimer: I have no stake in the ground here, except
advocating good security practices]

Fair enough, as long as this does not make the security considerations
sections null and void.

However, I am a little bit puzzled here, since this does not seem to
address any of the ambiguities noted in my comment (T-h). After all,
the only change to the text of Section 2.2 of
draft-herzog-static-ecdh-05 you suggest seems to be to replace the phrase
"It confirms that" by "It MUST confirm the following at least once per
recipient-certificate", without any further changes.

This does *not* address, since it is entirely unclear whether
a) one checks that public keys in the certificate are on a specific
curve (i.e., one does public key validation)
or
b) something more relaxed (such as checking that the claimed elliptic
curve domain parameters are the same, without checking the public keys
themselves;
c) whether one, in fact, checks the validity of the certificate that
included the public key

Ad #c:
Without checking the validity of certificates (item #c) {by performing a
cryptographic signature verification operation at least once}, one might
as well do away with certificates altogether, since no implicit key
authentication assurances can be obtained.

Ad #b:
By just checking that the certificate has a substring indicating the
purported domain parameters of the other entity's public key (item #b),
one does not seem to have any assurance that that public key is, in
fact, indeed of the proper form, i.e., on the curve and a generator of
the prime order cyclic subgroup of the curve indicated by the domain
parameters (unless the CA did those checks and by issuing the cert
attests to this and one indeed verifies the certificate itself
cryptographically).

Ad #a:
Without checking whether the public keys exchanged by both entities in
the protocol are on the same curve, one opens oneself up to a plethora
of potential attacks (small subgroup attack, invalid point attack, etc.
-- all well-documented in the cryptographic literature and also
referenced in the Security Consideration section).

It would help if you could comment on the lingering ambiguities I noted
in my original comment T-h (elaborated upon above with #a, #b, and #c)
and which, unless I misunderstand, are not taken away by your suggested
resolution. Further, it would help if you could indicate whether the
intention is to publish the draft with sufficient safeguards so as not
to succumb to well-documented vulnerabilities.

<<RS

Section 2.3:


   The receiver then retrieves the sender's certificate identified in
   the rid field, and extracts the EC public key(s) and domain
   parameters contained therein.  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]).



RS>>
Same concern as with (T-h) above.
<<RS
(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?
Neither Dr. Struik nor I could find OIDs for AES in counter mode, and so they 
remain absent from the Draft.


RS>>
Okay - if OIDs are the only "stairway to heaven".

Question:
Shouldn't we put together an I-D that specifies the CTR mode and on OID
for this??? It would be a shame not to have this available (or could we
refer to NIST SP 800-38A and does NIST have an OID for this???).
Any thoughts?

<<RS


(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).

I told Dr. Struik that I preferred to leave this out of the draft, and he (I 
believe) agreed.


RS>>
We can indeed deal with fostering speed-ups separately (as long as this
is not pushed in a cob-webbed corner!). The interesting thing is that
implementers of the draft could still move towards these "Friendly
ECDSA" techniques, without violating the current draft, so the door is
not completely closed on that one.
<<RS

Thanks all.




-- 
email: rstruik(_dot_)ext(_at_)gmail(_dot_)com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

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