On Wed, Apr 5, 2023 at 12:26 PM Eric Rescorla <e...@rtfm.com> wrote:
> Thanks for your feedback. Most of these are editorial comments and > so I think they're my decision as editor about which ones to take > absent some instruction from the chairs. > I agree concerning most of them. One just finds nitpicks if you read the whole thing carefully. The one thing I think is really substantive is the deprecation of TLS 1.0 / 1.1, since you have a strange nesting of MUSTs. I think a descriptive "NOT RECOMMENDED" approach would be better here. Then, describe that servers might choose to accept 1.0/1.1 if they don't actually care whether the traffic is secure. This is a very common pattern. I found a survey that showed popular public sites were likely to accept almost anything (SSL3, unencrypted traffic, etc).* I think this approach is more accurate, but also more critical in terms of security than what you have now. thanks, Rob * "In fact, the top 100 sites were more likely to still support SSL 3, TLS 1.0, and TLS 1.1 than servers with much less traffic." < https://www.f5.com/labs/articles/threat-intelligence/the-2021-tls-telemetry-report > > On Tue, Apr 4, 2023 at 10:43 PM Rob Sayre <say...@gmail.com> wrote: > >> Hi, >> >> I'm still not sure about the list/vector rename. Aside from that, here's >> what I found: >> >> > It tightens some requirements and contains >> > updated text in areas which were found to be unclear as well as other >> > editorial improvements. >> >> "It contains clarifications and tightened requirements." [let's assume >> some things were unclear and that editorial improvements are clarifications] >> > > Not all editorial improvements are clarifications. > > >> >> > Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by >> [RFC8996]. >> >> I know what's meant here, but deprecated does not mean forbidden. I think >> you want to say "NOT RECOMMENDED" in RFC 2119 words, and give a brief >> reason for that. [but keep reading] >> > > This isn't normative text. However 8996 is entitled "Deprecating TLS 1.0 > and TLS 1.1" so I think this > is fine. > > > >> > The protocol does not provide any forward secrecy guarantees for this >> data. >> > The server's behavior determines what forward secrecy >> > guarantees, if any, apply (see Section 8.1). This behavior is >> > not communicated to the client as part of the protocol. >> > Therefore, absent out-of-band knowledge of the server's behavior, >> > the client should assume that this data is not forward secret. >> >> Here, you use the term "out-of-band", but the PSK text replaced >> "out-of-band" with "external[ly]". I can't tell whether this usage is >> intentional. >> > > It is. The PSKs here are resumption PSKs. They're not external. The out of > band in > question is knowledge about the server behavior. > > > >> >> > Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS >> > 1.3 and receives a ClientHello at any other time, it MUST terminate >> >> "TLS 1.3 forbids renegotiation. If a server has negotiated TLS 1.3 and >> receives a ClientHello at any other time, it MUST terminate..." >> >> [No starting sentences with "Because"] >> > > I believe this is editor discretion. > > >> >> > 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. >> >> I think this makes my "NOT RECOMMENDED" suggestion above correct. A >> forbidden "MUST NOT" wouldn't need this text. >> > > I don't understand this argument. The point of this text is that people > are forbidden > to do previous versions by 8996, but we know some people won't so this is > backup guidance. I think this is fine. > > > > >> >> > Unless otherwise specified, trailing data is forbidden. >> > That is, senders MUST NOT include data after the structure in the >> > "extension_data" field. >> >> This doesn't seem like "MUST NOT", since it could be "otherwise >> specified". I think there needs to be a harsher choice made here, or just >> leave it out. >> > > This is actually fairly standard language. > > > >> > When processing an extension, receivers MUST >> > abort the handshake with a "decode_error" alert if there is data left >> > over after parsing the structure. This does not apply if the >> > receiver does not implement or is configured to ignore an extension. >> >> Again, doesn't seem like a "MUST". But the following text says "This does >> not apply", without clarifying what "this" is. >> > > I don't follow your argument here either. It's a MUST for any extension > you understand. > Obviously, if you don't understand it, you can't comply with this. I'll > attempt to clarify. > > >> > After checking ServerHello.random to determine if the server >> > handshake message is a ServerHello or HelloRetryRequest, clients MUST >> > check for this extension prior to processing the rest of the >> > ServerHello. This will require clients to parse the ServerHello in ... >> >> Another "this". Here, I think the text means "This requirement...", but >> usually a rewrite can fix these ambiguities. >> > > I don't think this one is unclear. > > >> > In the absence of some other specification to the >> > contrary, servers which are authenticating with an external PSK MUST >> > NOT send the CertificateRequest message either in the main handshake >> > or request post-handshake authentication. [RFC8773] provides an >> > extension to permit this, but has not received the level of analysis >> > as this specification. >> >> Another one of these "In the absence of..." paragraphs. Maybe these are >> intentional? They still sound really redundant to me. >> > > They're intentional because we know there is actually such an RFC, but you > have to > actually use it. > > >> > With a 128-bit key as in AES-128, rekeying 2^64 times has a high >> > probability of key reuse within a given connection. Note that even... >> >> It's almost always possible to drop "Note that..." >> > > It is possible, but I prefer to leave it as-is. > > >> The rest of this paragraph is really heavy on em dashes, and needs to be >> rewritten. Some of them seem to be parentheticals, but I would try to >> rewrite it as short sentences. >> > > I'll take a look. > > > >> > Note that it is common practice in some protocols to use the same >> >> Another "Note that" >> > > See above. > > >> >> > Note that purely deterministic ECC signatures such as deterministic >> ECDSA and EdDSA ... >> >> ... >> >> > If the resumption_master_secret has been >> > compromised, a resumption handshake with EC(DHE) gives protection >> > against passive attackers and a full handshake with EC(DHE) gives >> > protection against active attackers. >> >> Here, you mean "resumption_secret". >> > > Thanks. Good catch. > > >> >> > Note: This specification does not currently permit the server to send >> >> The old text was better. No "Note:". >> >> The "currently" part seems like the wrong thing to write in an immutable >> document. Maybe "TLS 1.3 does not currently..."? >> > > I don't think this is a problem. > > >> >> > In the absence of some other specification to the contrary, >> implementations... >> >> I must be missing the conversation on this stuff. How could anyone write >> a spec if every requirement was prefaced with "in the absence of some other >> specification to the contrary..." >> > > The purpose of this text is to signpost that we know that there might be or > in fact is is such a specification, as opposed to other requirements which > we don't have any reason to think that about. > > >> >> > Amplifying existing information leaks caused by side effects like >> > caching. An attacker... >> >> Not a complete sentence here. I think it's just a typo. >> > > Thanks. Will fix. > > -Ekr > > >> >> thanks, >> Rob >> >> >> >> On Tue, Apr 4, 2023 at 7:32 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> >> wrote: >> >>> >>> Hiya, >>> >>> On 05/04/2023 02:47, Sean Turner wrote: >>> > A post IETF 116 bump to make sure folks get their reviews in. If you >>> > look at the diffs from RFC 8446 you can see not that much has >>> > changed. We will also take “I read it and it looks good” response. >>> >>> I looked at the diff between 8446bis-07 and 8446 and it seems >>> fine to me. My only comment is that C.4 says one "SHOULD NOT >>> reuse a key share" - I'd be happier if that was a "MUST NOT" >>> but understand if we stick with SHOULD NOT. If there were a >>> good reference showing that it's quite feasible to never >>> deliberately re-use a key share, even at scale, that'd be a fine >>> addition. (I don't have such a reference to offer, >>> sorry;-) >>> >>> Cheers, >>> S. >>> _______________________________________________ >>> 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 >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
