> On 17 Feb 2017, at 18:58, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > Hiya, > > I've had a read of this and asked for IETF LC to start. > > My comments below can be handled with any other IETF LC > comments. > > Thanks, > S. > > - Bits of this are fairly complex reading, given that ECC > isn't trivial and nor are the changes nor how they were done > to keep some things more or less backwards compatible. It'd > help I think if we could say something more about > implementation status in the shepherd write-up.
In light of RFC 7942, I’ve added an Implementation Status section to my working copy (soon to be pushed to github). > - abstract: doesn't this need to say that this obsoletes > RFC4492 in the abstract text. (Yes, PITA formalities, I > know:-) Added. > - 5.1.1: "Note that other specifications have since added > other values to this enumeration." Could/should we reference > those others? I don't care, but someone will ask and it'd be > good to have the answer in the archive if it's "no, and > here's why…" I think not. Same as the main TLS spec doesn’t mention every GOST and CAMELLIA that people add, we don’t have to mention Brainpool. But I will note that some of these additions are not curves at all. > - 5.1.1: Is this text still correct: "secp256r1, etc: > Indicates support of the corresponding named curve or class > of explicitly defined curves." Do we need to say there that > we're ditching explicitly defined curves? Yes, it should. > - 5.2: Is this still right, given the deprecation of > compressed points earlier? " Note that the server may include > items that were not found in the client's list (e.g., the > server may prefer to receive points in compressed format even > when a client cannot parse this format: the same client may > nevertheless be capable of outputting points in compressed > format).” Right. The example no longer works. I’ll remove it and say that there’s no other options than uncompressed. > - 5.3: Doesn't this need a change: "...unless the client has > indicated support for explicit curves of the appropriate > type"? Maybe more change is needed in that para as well? I removed the whole sentence. There are no more explicit curves. > - section 6: Do we still need the *_NULL_* suites? Did we ever? But I’m sure somebody uses them somewhere for something. Unlike weak encryption, they don’t tend to end up being used when people encrypt things. > - Just checking, I assume this is down to editing history > but what happened to TBD1 and TBD2? There were determined :) These were Curve25519 and Curve448. We got temporary assignments so that Google and others could deploy them. Yoav
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
