Yoav, On Thu, May 4, 2017 at 1:59 PM, Yoav Nir <ynir.i...@gmail.com> wrote: > > On 4 May 2017, at 16:09, Kathleen Moriarty > <kathleen.moriarty.i...@gmail.com> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
