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

[Yoav Nir <[e-mail]>]

> 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 <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 <https://tools.ietf.org/html/rfc4492> 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 <https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-16#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 <https://tools.ietf.org/html/rfc5246>.

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

Yoav