Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

[Yoav Nir <[e-mail]>]

Hi.

Draft-17 submitted.

Yoav

> On 4 May 2017, at 23:09, Kathleen Moriarty <[e-mail]> wrote:
> 
> Yoav,
> 
> On Thu, May 4, 2017 at 1:59 PM, Yoav Nir <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> On 4 May 2017, at 16:09, Kathleen Moriarty
>> <[e-mail]> wrote:
>> 
>> I haven't approved it yet as I noticed there was no response (that I saw) to
>> Alexey's comment and no change in the draft as a result of his comments.
>> 
>> 
>> 
>> You mean these comments?
>> https://mailarchive.ietf.org/arch/msg/tls/MFs8aGEZsr-1P7o4_CB-VjxXRg0
>> 
>> I’ll quote them here:
>> 
>> 0) There is some general awkwardness in text talking about allowed points
>> formats, considering that only uncompressed form is now allowed. I don't
>> have recommendations about improving text, other than the following:
>> 
>> If no future formats are expected, it feels almost better to recommend
>> against inclusion of the Point formats extension, as lack of it means
>> uncompressed format anyway.
>> 
>> So this was addressed in draft -16:
>> 
>> OLD:
>> 
>>      Implementations of this document MUST support the
>>   uncompressed format for all of their supported curves, and MUST NOT
>>   support other formats for curves defined in this specification.  For
>>   backwards compatibility purposes, the point format list extension
>>   MUST still be included, and contain exactly one value: the
>>   uncompressed point format (0).
>> 
>> 
>> NEW:
>> 
>>      Implementations of this document MUST support the
>>   uncompressed format for all of their supported curves, and MUST NOT
>>   support other formats for curves defined in this specification.  For
>>   backwards compatibility purposes, the point format list extension MAY
>>   still be included, and contain exactly one value: the uncompressed
>>   point format (0).  RFC 4492 specified that if this extension is
>>   missing, it means that only the uncompressed point format is
>>   supported, so interoperability with implementations that support the
>>   uncompressed format should work with or without the extension.
>> 
>> 
>> 
>> 1) In Section 2.3, last paragraph: Does this paragraph apply only to 2.3
>> or does it also apply to 2.1 and 2.2? If the latter, then it needs to be
>> moved to section 2.
>> 
>> 
>> The content of the last paragraph was moved to a new section:
>> 
>> 2.4.  Algorithms in Certificate Chains
>> 
>>   This specification does not impose restrictions on signature schemes
>>   used anywhere in the certificate chain.  The previous version of this
>>   document required the signatures to match, but this restriction,
>>   originating in previous TLS versions is lifted here as it had been in
>>   RFC 5246.
>> 
>> 
>> 
>> 2) In Section 6:
>> 
>>   Server implementations SHOULD support all of the following cipher
>>   suites, and client implementations SHOULD support at least one of
>>   them:
>> 
>>   o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>   o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>   o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>>   o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
>> 
>> GCM ciphers are not listed in the table earlier in the same section. They
>> are defined in RFC 5289. This document doesn't have any reference to RFC
>> 5289 and GCM ciphers are not discussed anywhere else in the document.
>> 
>> 
>> Seems like I missed this one.
> 
> Thanks, let me know when the update is ready.
> 
>> 
>> Yoav
>> 
>> 
> 
> 
> 
> --
> 
> Best regards,
> Kathleen