Hi. Draft-17 submitted.
Yoav > On 4 May 2017, at 23:09, Kathleen Moriarty <kathleen.moriarty.i...@gmail.com> > wrote: > > Yoav, > > On Thu, May 4, 2017 at 1:59 PM, Yoav Nir <ynir.i...@gmail.com > <mailto: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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
