Subject: [TLS] AD review of draft-ietf-tls-rfc4492bis-12.txt

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Feb 2017 16:58:31 +0000

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.

- abstract: doesn't this need to say that this obsoletes
RFC4492 in the abstract text. (Yes, PITA formalities, I
know:-)

- 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..."

- 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?

- 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)."

- 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?

- section 6: Do we still need the *_NULL_* suites?

- Just checking, I assume this is down to editing history
but what happened to TBD1 and TBD2?