Re: [Cfrg] Curves specification possibly complete.

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 26 August 2015 21:51 UTC

Message-ID: <55DE34E7.4020302@cs.tcd.ie>
Date: Wed, 26 Aug 2015 22:51:35 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Adam Langley <agl@imperialviolet.org>, "cfrg@irtf.org" <cfrg@irtf.org>
References: <CAMfhd9Vn_ZDoTG7_Yciav6jDAbXX6gX-NiMpkXA0qicLp=BMZg@mail.gmail.com>
In-Reply-To: <CAMfhd9Vn_ZDoTG7_Yciav6jDAbXX6gX-NiMpkXA0qicLp=BMZg@mail.gmail.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/cOxbo0lx25QwKHaO7i4edwtmAOU>
Subject: Re: [Cfrg] Curves specification possibly complete.
Precedence: list


Drat! I was half done with -05 and there you go making it better:-)

I've only one substantive comment so far though and some (very
ignorable nits). I hope to get time to read it in more detail but
since that mightn't happen or you may be on -99 before I get to
it, my comments on -05 are below.

I do think this is sufficiently baked to go forward in case that
isn't clear.

Cheers,
S.


Only one substantive comment:

- The (currently missing) security considerations (or somewhere)
should describe why Curve25519 is ok when used in contexts where we'd
otherwise ask for 128 bit strength, (basically because it's close
enough), and also why the 224 bit level is considered a good choice.
There was a lot of debate on the list about that, and I've seen the
issue come up elsewhere so this text will avoid re-litigating that and
should be worthwhile even if it takes a little time to agree.

nitty-nits: (which are ok to ignore)

- title/abstract: we're not including the signature scheme based on
these curves in this document. But we do talk about ECDH.  Shouldn't
that be reflected in the title/abstract?

- intro: wouldn't a reference to RFC6090 be useful as well as or
instead of [SEC1]? 6090 does after all have references to very old
descriptions of ECC.

- intro, para 2: wouldn't it be more accurate to say that these curves
lend themselves to natural constant-time implementations rather than
say that they "support" constant time?

- intro: references for Montgomery and Edwards would be good.  (And
ones suited for implementers, not mathematicians.)

- section 5, para 1: be good to say that the 32 byte output is for
X25519 and the 56 for X448. (Yes, it's obvious but good to be
precise.)

- section 5, para 2: you start with u[0] and end with u[n] - isn't it
more common to end with u[n-1] there? In this case it doesn't matter
as you don't say n=32 or n=56 but maybe there's a small chance that
might trip up some coder somewhere (though it's hard to see how so
consider this a totally pedantic nit, offered just to see who else
wants to be pedantic:-)

- section 5: the RFC editor will ask if you want "CODE BEGINS" markers
around the python code.

- section 5, last para on p8: you say here it's important to not do a
bad thing, but you don't say (or provide a reference as to) how to
avoid the bad thing.

- I think section 7 could now be placed in an appendix.

- section 7: trace of Frobenius needs a reference, as do MOV degree
and CM discinimant. If the current references explain those then say
so.

- I think this draft should have security considerations that say a
little about good implementations, mainly via reference if possible.

- An RFC6982 "implementation status" section could be useful here as I
guess we don't really want all and sundry writing the code for all
this. Note that that could be useful even if the text doesn't end up
in the RFC - people will find it anyway. (And I think 6982 was wrong
in saying such sections should be deleted before RFC publication.)

To re-iterate - all these nits are just that and I am ok if they are
utterly ignored.

[Cfrg] Curves specification possibly complete. Adam Langley
Re: [Cfrg] Curves specification possibly complete. Ilari Liusvaara
Re: [Cfrg] Curves specification possibly complete. Adam Langley
Re: [Cfrg] Curves specification possibly complete. Ilari Liusvaara
Re: [Cfrg] Curves specification possibly complete. Deirdre Connolly
Re: [Cfrg] Curves specification possibly complete. Deirdre Connolly
Re: [Cfrg] Curves specification possibly complete. Jim Schaad
Re: [Cfrg] Curves specification possibly complete. Watson Ladd
Re: [Cfrg] Curves specification possibly complete. Jim Schaad
Re: [Cfrg] Curves specification possibly complete. Adam Langley
Re: [Cfrg] Curves specification possibly complete. Adam Langley
Re: [Cfrg] Curves specification possibly complete. Adam Langley
Re: [Cfrg] Curves specification possibly complete. Simon Josefsson
Re: [Cfrg] Curves specification possibly complete. Adam Langley
Re: [Cfrg] Curves specification possibly complete. Yoav Nir
Re: [Cfrg] Curves specification possibly complete. Stephen Farrell
Re: [Cfrg] Curves specification possibly complete. Adam Langley
Re: [Cfrg] Curves specification possibly complete. Stephen Farrell