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

[Yoav Nir <[e-mail]>]

> On 17 Feb 2017, at 18:58, Stephen Farrell <[e-mail]> 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