Re: [Cfrg] [TLS] Unwarrented change to point formats

On Sun, Jul 27, 2014 at 11:25 AM, Paterson, Kenny
<Kenny.Paterson@rhul.ac.uk> wrote:
> Watson,
>
> There was certainly support for Curve25519 at the CFRG interim phone conference, from my reading of the transcript.
>
> I don't think the reasons for the TLS WG to ask for our input are nebulous, as you put it. I'd say they were taking a responsible approach, charging us as experts to explore the alternatives carefully and make recommendations. This choice will affect the future security of TLS for years - or decades - to come. So we have to get it right.

No one has indicated any weakness in any of the options: to a
first-order approximation the choice will not impact security. (There
is a second-order effect where the performance of 512-x vs
448-Goldilocks will influence choices about which security level to
use, but it's second order, and
I think we're sensitive enough to performance to minimize it) At the
128 level there is really nothing to get excited about. We're going to
get it right: we can't get it wrong. (Assuming we've checked the
curves independently)

At the higher security levels the debate become slightly more
interesting: we need E-521 as it's the most efficient curve above
2^512 (I'm ignoring the constant on Pollard rho, which everyone seems
to do nowadays). The question becomes Ed448 vs Curve41417, where
whichever
is faster wins out. (Or the NUMS curve of intermediate size).

(There is one question of point format: for odd reasons people seem to
think ECDH and ECDSA keys should be interchangeable, and so want
twisted Edwards everywhere. But we don't know anything about ECDSA
that would let us do the analysis to say that is okay!)

>
> That request to us does not mean anyone is ignoring existing drafts, as you write. I am also not aware of this IETF-wide requirement that you mention. I believe it's a "nice to have", but not a hard requirement. Can you point to something more solid that is demonstrably a consensus view?

I may have read too much into emails indicating possible wider adoption.

>
> You will note from my previous emails summarising the meeting in Toronto that backwards compatibility with the existing wire format is regarded as being desirable but not essential by the TLS WG leadership. If it can be done, it will make adoption easier; if not, we can change it, but it will need some careful drafting to make sure it's crystal clear.

This is (partially a) nonissue: RFC 4492 defines points as opaque
bytevectors, and provides a set of point formats to describe their
formating, so there is no formatting requirement on the point. There
is one for signatures, but as we are not introducing new signatures we
don't need to worry about it.

>
> The fact that the small group who run OpenSSH has adopted a couple of schemes based on a particular curve does not necessarily make that curve the right choice for TLS. I also don't regard that as wide adoption, as you put it. I'm not aware of a public, requirements-driven process behind their choice. That's what we are attempting here.

When is the last time you used SSH and it wasn't OpenSSH? Furthermore,
they are not alone: most public greenfield crypto projects I have seen
use Curve25519 or variants such as Curve41417.

On what criteria can we possibly pick a curve? All the criteria we've
mentioned are met by both sides. It will come down to narrow
performance differences, which turns into a compiler tickling
competition. (Automatic compiler ticklers are useful here).  Maybe
when we start measuring implementations there will be a clear set of
choices, but I predict we will end up basically flipping a coin: so
much for requirements-driven!

Sincerely,
Watson Ladd
>
> Your continued inputs to the process are most welcome.
>
> Regards
>
> Kenny
>
>> On 26 Jul 2014, at 18:59, "Watson Ladd" <watsonbladd@gmail.com> wrote:
>>
>> Dear all,
>> Curve25519 was a draft. Curve25519 came back with good reviews from
>> the CFRG. End of story? No: the TLS WG leadership has decided to ask
>> for the choice of curves, on nebulous criteria, ignoring existing
>> drafts, on the basis that the curves must be applicable "IETF wide".
>>
>> I don't see the reason for this, especially given that OpenSSH has
>> implemented and deployed Curve25519 and Ed25519, complete with
>> Montgomery form on the wire.  Arguing that we need twisted Edwards
>> point formats everywhere for consistency with existing libraries
>> ignores what has already been deployed and widely adopted.
>>
>> Sincerely,
>> Watson Ladd
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin