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

[David McGrew <[e-mail]>]

Hi Stephen,

On Mar 9, 2011, at 12: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.)
>

I think that RFC6090, combined with NIST SP800-56A, could be used as  
the sole normative reference for static-static ECDH (the vanilla  
flavored variant, not the cofactor variant).  I sketched some thoughts  
in that direction in a separate email.  Jonathan, what do you think?

Jonathan was correct that RFC6090 can't be used as a reference for the  
cofactor variant.

David


> 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
>>>
>>
>>
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir