On Wed, Apr 5, 2023 at 12:53 PM Eric Rescorla <e...@rtfm.com> wrote:
> > > On Wed, Apr 5, 2023 at 12:50 PM Rob Sayre <say...@gmail.com> wrote: > >> 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 don't see how we can use NOT RECOMMENDED here, because we already have > an RFC which prohibits the use of TLS 1.0 and TLS 1.1 and we're not > contradicting > that. The purpose of the text you highlight is to address people who are > nonconformant > with that RFC. > I see your point. RFC8996 does say "MUST NOT", but that's not deprecation. It's prohibition, as you say. So, the title of the document is confusing. I still think what it's in this document is confusing, because it says "if you don't follow this MUST, you have to follow this MUST...". But I can see this situation is kind of messy, so I think it's editorial. thanks, Rob > >> 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
