I made a PR on github with some suggested fixes for essentially editorial issues. Some more substantive comments below. There seem to be a handful of instances where we restate essentially the same normative requirement (e.g., "SHOULD NOT use static FFDH keys") in multiple places in the document. I often recommend to just use the normative keywords in one location and use normal prose to describe the requirement when it is discussed elsewhere, to avoid the risk that the two different phrasings of the normative requirement could be interpreted in slightly different (conflicting) ways. Section 3.1.1 * Implementations MUST NOT negotiate TLS version 1.0 [RFC2246]. Rationale: TLS 1.0 (published in 1999) does not support many modern, strong cipher suites. In addition, TLS 1.0 lacks a per- record Initialization Vector (IV) for CBC-based cipher suites and does not warn against common padding errors. This and other recommendations in this section are in line with [RFC8996]. I'm not really sure why this is the best place to put the only mention of RFC 8996 in relation to the requirements of this section. 8996 also forbids both SSL versions and TLS 1.1, so why is TLS 1.0 special? Perhaps it's better to move the 8996 reference into the list preface, noting that we are building on top of its guidance and seek to impose slightly more stringent/stronger requirements? * Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS. [...] * Implementations SHOULD support TLS 1.3 [RFC8446] and, if implemented, MUST prefer to negotiate TLS 1.3 over earlier versions of TLS. It's very disappointing to me to see that we label a TLS 1.3-only implementation as non-compliant with the BCP for TLS usage; such an implementation is more secure than a joint 1.2+1.3 implementation. That said, I assume that the WG discussed this topic extensively and it seems somewhat unlikely that I have any new contributions to that discussion. (Similarly for DTLS 1.3.) * Implementations of newly-developed protocols SHOULD support TLS 1.3 only with no negotiation of earlier versions, since there is no need to allow legacy endpoints that support TLS 1.2. This seems like it is really more of guidance to protocol designers than implementors thereof (yet we say "implementations of") -- if a new protocol comes out that says "use TLS" (with no version requirements), an implementation that limits itself to TLS 1.3 as this text recommends would fail to interoperate with a different implementation of that protocol that uses only TLS 1.2. Section 3.2 or via a method for dynamically upgrading a channel from unencrypted to TLS-protected (e.g., STARTTLS, which is used in protocols such as SMTP and XMPP). [...] FWIW, draft-ietf-nfsv4-rpc-tls has a "STARTTLS for NFSv4". * HTTP client and server implementations MUST support the HTTP Strict Transport Security (HSTS) header [RFC6797], in order to allow Web servers to advertise that they are willing to accept TLS-only clients. * Web servers SHOULD use HSTS to indicate that they are willing to accept TLS-only clients, unless they are deployed in such a way that using HSTS would in fact weaken overall security (e.g., it can be problematic to use HSTS with self-signed certificates, as described in Section 11.3 of [RFC6797]). Looking at https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-08#section-9.5 calls to mind another scenario in which HSTS use is contraindicated: when there are resources available only on the "http" origin that are not accessible via "https" (or must be accessed via a different request path). Only when we specialize from HTTP into "the Web" do we have a strong expectation of equivalence of http and https resources (e.g., RFC 6265 cookies begin to erase the isolation between schemes). I do note that the two bullet points I quote begin, respectively, with "HTTP" and "Web", so in some sense this distinction is already being made. But it is a quite subtle distinction, and I wonder if we might be able to make some small tweaks (perhaps just adding another reference or two) to provide a hint to the diligent reader. I don't have any good suggestions off the top of my head, but perhaps a friendly ART AD would be able to oblige. * Ticket keys MUST be changed regularly, e.g., once every week, so as not to negate the benefits of forward secrecy (see Section 7.3 for details on forward secrecy). Old ticket keys MUST be destroyed shortly after a new key version is made available. * For similar reasons, session ticket validity MUST be limited to a reasonable duration (e.g., half as long as ticket key validity). The "half as long" recommendation seems to suggest a desire for seamless key rotation (i.e., "force clients to get new tickets often enough that they will get one with a newer key before their old one expires"), but the "MUST be destroyed shortly after" requirement seems to preclude such an operational scenario. While resumption is just an optimization and it's not like we're setting ourselves up for handshake failures, it does seem like we might want to make our guidance paint a consistent picture on the expected behavior around key-rotation events. (N.B. that the above assumes that the "ticket keys" are the "ticket-encryption keys" held solely by the server and used for self-encrypting the stateless blob of session information, as I propose in my PR.) * TLS 1.2 does not roll the session key forward within a single session. Thus, to prevent an attack where a stolen ticket key is used to decrypt the entire content of a session (negating the concept of forward secrecy), a TLS 1.2 server SHOULD NOT resume sessions that are too old, e.g. sessions that have been open longer than two ticket key rotation periods. Note that this implies that some server implementations might need to abort sessions after a certain duration. This is a slightly pedantic point, but the initial statement here is "SHOULD NOT resume sessions", which relates to a separate scenario than "might need to abort sessions". The latter only comes into play if the desire is to avoid using the single session key for too long a duration, whereas not-resuming is a limitation only on the use of the ticket associated with the session key, and makes no limitation on the actual use of the session key for protecting application traffic. Do we care more about the resumption event or ongoing use of the corresponding session key? Separately, I have in my PR attempted to impose a distinction between the "ticket-encryption key" (private to the server) and the "session key" (the output of the handshake, shared by both client and server and used to encrypt traffic). I am not actually sure if the "stolen ticket key" phrase is intended to refer to the "ticket-encryption key" or the "session key" (or either), so some clarification would be appreciated. TLS 1.3 provides the powerful option of forward secrecy even within a long-lived connection that is periodically resumed. Section 2.2 of [RFC8446] recommends that clients SHOULD send a "key_share" when initiating session resumption. In order to gain forward secrecy, this document recommends that server implementations SHOULD respond with a "key_share", to complete an ECDHE exchange on each session resumption. [...] It feels a little strange to me for this text to focus so heavily on whether or not a "key_share" is present while making no mention of the "psk_key_exchange_modes" extension that is used to actually negotiate the PSK+ECDHE combination. While on careful reading this text does appear to be correct (it quotes what RFC 8446 says for clients to do and then offers guidance on how servers should respond), I would suggest a minor tweak like "...SHOULD select the "psk_dhe_ke" PSK key exchange mode and respond with a "key_share", ..." Section 3.5 TLS 1.2 clients and servers MUST implement the renegotiation_info extension, as defined in [RFC5746]. Is this statement intended to also impose any requirement to implement the TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite value? It might be worth making an explicit statement about the SCSV, which is related to but not exactly the same as the extension. TLS 1.2 clients MUST send renegotiation_info in the Client Hello. [...] Similarly, is this intended to allow for using the SCSV rather than the empty extension? If I remember correctly, OpenSSL always uses the SCSV and never sends the empty extension in the ClientHello. A related attack resulting from TLS session parameters not properly authenticated is Triple Handshake [triple-handshake]. To address this attack, TLS 1.2 implementations SHOULD support the extended_master_secret extension defined in [RFC7627]. It surprised me that EMS is only a "SHOULD" given the scope of potential issues if it is absent. I tried to look for previous WG discussion on this point, but found essentially nothing in the list archive for search query "EMS" or "extended master secret". Was there previous discussion resulting in this being a "SHOULD" vs "MUST" or should we have such a discussion now? Section 3.8 TLS implementations (both client- and server-side) MUST support the Application-Layer Protocol Negotiation (ALPN) extension [RFC7301]. In order to prevent "cross-protocol" attacks resulting from failure to ensure that a message intended for use in one protocol cannot be mistaken for a message for use in another protocol, servers SHOULD strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]: "In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal no_application_protocol alert." [...] It feels a bit strange to have a "MUST support [RFC7301]" statement and follow it up with only a "SHOULD strictly enforce [part of RFC 7301]". If you MUST do it, don't you need to always do it, not just sometimes (as SHOULD would have it)? Protocol developers are strongly encouraged to register an ALPN identifier for their protocols. This applies to new protocols, as well as well-established protocols. I'd consider following this with a clause "but strict enforcement of ALPN usage may not be feasible when the ALPN identifier is registered for a well-established protocol". Section 4.1 Rationale: Based on [RFC3766], at least 112 bits of security is needed. 40-bit and 56-bit security are considered insecure today. TLS 1.2 never negotiates 40-bit or 56-bit export ciphers and such ciphers are not supported at all in TLS 1.3. I don't think I understand the basis for the last sentence here -- while a TLS 1.2 implementation conformant to this BCP will never negotiate export ciphers, I don't see that it's intrinsically a property of TLS 1.2 to not do so. For example, OpenSSL 1.0.2 seems to be willing to negotiate such ciphers for TLS 1.2. Section 4.2 When using ECDSA signatures for authentication of TLS peers, it is RECOMMENDED that implementations use the NIST curve P-256. In addition, to avoid predictable or repeated nonces (that would allow revealing the long term signing key), it is RECOMMENDED that implementations implement "deterministic ECDSA" as specified in [RFC6979] and in line with the recommendations in [RFC8446]. Did we consider adding a note that when hardware-fault or similar attacks are a concern, randomness and deterministic signing might be combined, as investigated in draft-mattsson-cfrg-det-sigs-with-noise? There is some text to this effect in https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs-12#section-2.1.1 that might be used as a starting point. Section 4.5 As noted in [RFC3766], correcting for the emergence of a TWIRL machine would imply that 1024-bit DH keys yield about 65 bits of equivalent strength and that a 2048-bit DH key would yield about 92 bits of equivalent strength. [...] I didn't find the specific values for these bit strengths precomputed in 3766 in a quick search; I assume that there is some formula being used but we have to plug in our own numbers to get the values listed here. I did see https://datatracker.ietf.org/doc/html/rfc3766#section-5.1 say essentially "subtract 11 bits of strength" but that doesn't help me line these numbers up to other ones I'm used to seeing. Section 7.2 Section 4.2 above recommends the use of the AES-GCM authenticated encryption algorithm. Please refer to Section 11 of [RFC5246] for general security considerations when using TLS 1.2, [...] The referenced section itself just says "security issues are discussed throughout this memo" and mentions a few appendices. Perhaps the section reference is not adding much for us and we should just reference 5246 in its entirety? Section 7.5 For an up-to-date survey of the status of OCSP deployment in the Web PKI see [Chung18]. Is a reference from 2018 still "up-to-date" in 2022? the status_request extension differs between TLS 1.2 and 1.3. As a matter of local policy, server operators MAY request that CAs issue must-staple [RFC7633] certificates for the server and/or for client authentication, but we recommend to review the operational conditions before deciding on this approach. Do we believe that the operational considerations in question are sufficiently described by RFC 7633 or might there be an additional resource to reference here?