> 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 <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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
