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

[Stephen Farrell <[e-mail]>]

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

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?

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

Thanks,
Stephen.

On 09/03/11 18:53, Brian Weis wrote:
> Hi Jonathan,
> 
> No objections.
> 
> Thanks,
> Brian
> 
> On Mar 9, 2011, at 10:34 AM, Herzog, Jonathan - 0668 - MITLL wrote:
> 
>>
>> On Mar 8, 2011, at 12:13 PM, Brian Weis wrote:
>>
>>>>>>
>>>>>>> 2. Reference [SEC1] is heavily referenced in this document, for both a definition of ECDH and specific methods for using ECDH. But it would be good to also mention RFC 6090, which is the best IETF document describing ECDH.
>>>>>>
>>>>>> I was not previous aware of this RFC-- my bad. I have added it as an informative reference, but continued to refer to [Sec1] as the normative reference for the ECDH operation. Or do you think that RFC 6090 should be the normative reference?
>>>>>
>>>>> I would suggesting using RFC 6090 for a normative reference to ECDH if you need such a reference. But I don't believe RFC 6090 discusses static-static consideration or issues at all, so for that [Sec1] seems to be the appropriate normative reference.
>>>>
>>>> I'm a little uneasy with using RFC 6090 as a normative reference for ECDH, as my impression is that the rest of CMS uses SEC1 as the normative reference. (See RFC 5753.) This may be because RFC 6090 is so new, but I'm worried that switching to RFC 6090 as the normative reference for ECDH will introduce subtle incompatibilities.
>>>>
>>>> Also, RFC 6090 doesn't seem to include the cofactor ECDH operation (I think), or the use of the SharedInfo/ukm value.
>>>>
>>>> Given this, do you mind if I keep SEC1 as normative and use RFC 6090 as informative?
>>>
>>> Sure, that's fine.
>>
>>
>> I've thought a little more about this, and change my proposal to:
>>
>> * Reference RFC 6090 for ECDH in general, but
>> * SEC1 for co-factor ECDH, the public-key validation primitives, and the key-derivation function (KDF).
>>
>> Unfortunately, none of those algorithms in the second bullet are present in RFC 6090. (Though the security considerations of RFC 6090 discuss why one would want to validate public keys, it doesn't describe how to do so.)
>>
>>
>> Any objections?
>>
>> Thanks.
>> -- 
>> 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
>>
> 
>