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? - Curve25519 and Curve448 are called "X25519" and "X448" in the (looks to be imminently sent to RFC editor) 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). - 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. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
