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

[Stephen Farrell <[e-mail]>]

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