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

[Stephen Farrell <[e-mail]>]

Hi Jonathan,

On 09/03/11 21:09, Herzog, Jonathan - 0668 - MITLL wrote:
> 
> 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?

To be honest, I don't know for sure. I'm not familiar with how
NIST do or don't handle IPR so I don't know if the outcome
here will or won't make it easier for implementers to decide
whether or no to adopt this. But I think you're definitely
working in the right direction in the thread with David so
that's good.

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

I wish;-) Not sure I've seen an RFC about ECC that didn't
come with an IPR declaration from them attached. (Though
the content of those declarations is improving.)

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

I'm thinking of schemes from some years ago where the
requirement was to be able to decrypt outbound mails at
the outbound MTA when sender private values had been
centrally generated. I don't really recall any other
specific benefit of static-static.

> but I'm fairly sure it's not our motivation.

Sure. I wasn't trying to say it was.

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

I think that's useful context for the intro.


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

To be honest I'll have to read the draft again to answer
that, and its late here. Tomorrow.

Cheers,
S.




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