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

On Mar 11, 2011, at 7:10 PM, Rene Struik wrote:

> 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.)
[snip]

> > > > > (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.
I believe this is more-or-less correct.

> 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.
This Draft does not forbid verification and validation of certificates. Like 
RFC 5753, it is merely silent on the issue. My personal opinion is that this is 
as it should be, as issues of certificate generation, distribution, validation 
and verification are out of scope of this Draft. 


> 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).
While the CA may have performed these checks, it is not required by this 
document. (In fact, it can't be-- there is no field in the certificate by which 
the CA can indicate that such a check has been done.)


> 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).
I agree.


> 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

The ambiguities remain. The Draft is silent on when and how the certificates 
are verified and validated, or when/how the public-key parameters of the ECC 
key are validated. The first is out of scope, and the second is hindered by IPR 
considerations. But again, I note that:

1) The draft does not *prohibit* validation of the public-key parameters, and
2) This Draft mirrors the RFC 5753 treatment of the same issues.

Yes, The Draft would be better (meaning that the described system would be more 
secure) if it mandated the validation of the public-key parameters. But my read 
of the landscape is that were that the case, the IPR considerations would 
derail approval of the Draft. So the question is this:  given that RFC 5753 
also lacks these validation mandates, is the world less secure with this Draft 
augmenting RFC 5753, or with just RFC 5753 and without this draft?

[snip]


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

I couldn't find anything in SP 800-38A by searching on 'OID', 'ASN', or 
'identifier'. 

It may be worthwhile to create OIDs for counter-mode, but that would be outside 
the scope of this Draft.


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


In case you didn't see through other channels, we have submitted the -06 
version of this draft. It's waiting for manual approval, so I attach it to this 
email for your perusal.

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

draft-herzog-static-ecdh-06.txt
Description: Text document

smime.p7s
Description: S/MIME cryptographic signature

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