Re: [secdir] Secdir review of draft-herzog-static-ecdh-05

["Herzog, Jonathan - 0668 - MITLL" <[e-mail]>]

On Mar 9, 2011, at 3:31 PM, Stephen Farrell wrote:

> 
> Hi,
> 
> I've three concerns about this.
> 
> 1) Now that we have 6090, if there's a way to do any ECC stuff
> that can be built *only* on that, then that IMO gives a much
> better basis on which implementers might have confidence in
> their IPR situation. I think every reference to e.g. [SEC1]
> included muddies those waters somewhat and hence may further
> delay widespread adoption of ECC. Since the authors presumably
> would like to see adoption, I wonder is there any way to
> excise [SEC1] entirely and just use 6090 or other things with
> perhaps clearer IPR? (If there are technical issues with how
> to only use 6090 perhaps checking with cfrg and/or the authors
> of 6090 would help.)

We currently (in the -06 version, not yet submitted to the IETF) cite SEC1 for only the following:

1) Co-factor ECDH,
2) Validation of public-key parameters (both full and partial), and
3) A key-derivation function.

I am sure we can find another RFC to cite for (3). Unfortunately, however, neither (1) nor (2) seem to be in RFC 6090. (At least, I didn't see it there. I could be wrong.)

I just realized, however, that we can cite NIST SP 800-56A for both (1) and (2). Interestingly, that SP only permits/specifies static-static cofactor ECDH, not static-static standard ECDH. But that may not be relevant-- we can still cite RFC 6090 for standard ECDH.

So, I propose to replace SEC1 with SP 800-56A for (1) and (2), and some other RFC for (3). Would that address your concerns?



> 2) If [SEC1] remains as a reference, do we expect to get an
> IPR declaration related to this? Have the authors asked anyone
> from Certicom?

We have not asked anyone from Certicom, no.

But if we remove SEC1 entirely, does the issue become moot?


> 3) As far as I recall the only use-case specific to static-static
> is that it allows employers to wiretap much more easily that
> ephemeral-static. Am I right there?


I'm not sure what you mean by this, but I'm fairly sure it's not our motivation. We propose this draft because we would like to use CMS in an environment where:

1) Participants must use Suite-B algorithms, and therefore cannot use ECMQV, and

2) Participants will have certified ECDH keys but not certified signature keys. (Yes, ECDH keys are mathematically identical to ECDSA keys, but our participants will be constrained by various policies and will be unable to use their ECDH keys for ECDSA signatures.)

Without this Draft, CMS supports only ECMQV (which we cannot use) and ephemeral-static ECDH. In our setting, then, there is no way for recipients to cryptographically ascertain the identity of a message's sender. Now (and as we explain in the Security Considerations) it is true that this Draft does not fully solve the problem of data authentication in the fully general case. But (1) it gets fairly close, at least in the case of a single recipient, and (2) we believe that the 'attack' described in the Security Considerations is better addressed by a separate Draft. 


> (Its been a while.) If not,
> then I would suggest adding some use-case so that people might
> know when to go for this setup and when to go for
> ephemeral-static. If I am right above, then I think that warrants
> some security consideration and even more guidance as to when
> its appropriate to use static-static. (And I'd have to wonder
> if its worthwhile as an RFC personally, but then I guess some
> "customers" do like static-static for exactly this reason.)

Given what I say above, would you rather see more explanation in the Security Considerations, or to the discussion of our motivations in the Introduction?

-- 
Jonathan Herzog							voice:  [phone]
Technical Staff							fax:    [phone]
Cyber Systems and Technology Group		email:  [e-mail]
MIT Lincoln Laboratory               			www:    http://www.ll.mit.edu/CST/
244 Wood Street    
Lexington, MA 02420-9185