Hi Ilari > On 19 Oct 2015, at 8:14 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > On Mon, Oct 19, 2015 at 06:58:52PM +0300, Yoav Nir wrote: >> Hi >> >> I’ve submitted version -04 of this draft, incorporating the new curves >> Curve25519 and Curve448. >> >> I’m sorry to say that I have made the merge far too quickly and the result >> is quite sketchy, but I did beat the deadline. >> >> So I’m hoping to complete the merge soon. > > Some comments: > > - The document seems to lack obsoletes RFC4492 (or even updates > RFC4492). Isn't this supposed to supercede that document?
Yes. I’ve just updated this in https://github.com/tlswg/rfc4492bis > - Curve25519 and Curve448 are called "X25519" and "X448" in the > (looks to be imminently sent to RFC editor) draft. The functions are called X25519 and X448 (Shouldn’t it have been X4482241? Probably not). But the curves are called Curve25519 and Curve448 as is the title of sections 4.1, 4.2, 6.1, and 6.2 in the CFRG draft. > - In public key validation, X448 resists invalid point attacks > the same way as X25519 (of course, all bits of X448 public > keys can be nonzero, as the value can get to almost 256^56). > - The document still does have restrictions on algorithms used > to sign the certificate. AFAIK, TLS 1.2 (RFC5246) lifted all > such restrictions (at least sections 2.2, 5.3 and 5.6). Weird. I had intended to do that. I will create a pull request for this. > - Do we want to keep ECDH client keys? Those were used in one > recent exploit against one implementation of TLS. And using > one destroys forward secrecy anyway. > - Is this document meant to also include the CFRG signatures > work? The interfaces to functions are already known. That is the intention. A PR is welcome. Yoav _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
