Thanks Yoav, Those all look like fine resolutions for my comments.
Cheers, S. On 02/03/17 06:47, Yoav Nir wrote: > >> 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: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
