On Mon, May 22, 2023 at 1:09 PM Rob Sayre <say...@gmail.com> wrote:
> On Mon, May 22, 2023 at 12:59 PM Christopher Wood <c...@heapingbits.net> > wrote: > >> We trust the editors will faithfully enact all editorial changes they >> agree with as the document moves forward in the process. If there were >> non-editorial comments that we overlooked, could you please resurface them? >> > > Hi, > > I made these comments about 1.5 months ago, so I hope it doesn't seem like > I'm requesting a particularly quick turnaround. > Yes, this is my mistake. I just went through the Github issues and forgot to deal with this e-mail. I will create a PR for these. > There were a couple obvious corrections EKR agreed with, but aren't done. > These should be fixed before IETF Last Call. > > The one real problem (imho) with the document is nested MUST requirements: > https://mailarchive.ietf.org/arch/msg/tls/6x0uEVIUCBwMOIaV3UBzqeRt6Ys/ > > EKR called this "guidance", but RFC 2119 says MUST is "an absolute > requirement". The document needs to use the 2119 requirements language > correctly. I understand the goal, which is to preserve wire-format > compatibility in older TLS versions, even though they have security flaws. > As you indicate, the context here is that RFC 8996 forbids TLS < 1.2, but we know people might ignore that and thus this text is intended to provide requirements for people who do so. It's an inherently contradictory situation, but also the one we find ourselves in. With that in mind, you seem to be making three points: > Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS > versions below 1.2; implementations which do not follow that guidance > MUST behave as described above. Your complaint seems to boil down to the word "guidance", but the word used there doesn't have normative force, so I think this is an editorial issue. I agree we should also cite E.5, and I can cite that in my PR. Appendix E.5: > > The security of SSL 2.0 [SSL2], SSL 3.0 [RFC6101], TLS 1.0 [RFC2246], > > and TLS 1.1 [RFC4346] are considered insufficient for the reasons > > enumerated in [RFC6176], [RFC7568], and [RFC8996] and they MUST NOT > > be negotiated for any reason. > Here, I would end with "...for any reason in applications that require a > secure channel." I don't think that this is a good change. 8996 just flat out prohibits them and so we should match that. > > > Implementations MUST NOT send an SSL version 2.0 compatible CLIENT- > > HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an > > SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT > > RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in > > order to negotiate older versions of TLS. > > Without the little trailing text I added above, this seems a little > contradictory. The thinking here is the document says this is NOT > RECOMMENDED, but it's something they MUST NOT do, unless you only mean TLS > 1.2 here. I don't see the problem here. You MUST NOT negotiate TLS < 1.2 and you are NOT RECOMMENDED to use the SSLv2 CH to negotiate TLS 1.2. Perhaps your objection is to the use of the plural "older versions" but again, we know that some people will ignore the E.5 requirement and the point here is that even if they do so, they should still not do this. With all that said, if there is WG consensus to make these changes, I'll of course do so. Deferring to the chairs on how to proceed. -Ekr -Ekr _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
