I'm not sure I agree with that interpretation of the situation in ETSI, but I also don't think it's useful to try to import a definition of "profile" from another SDO with different practices, so I don't see much point in debating what is happening in ETSI.
On the text itself, we have: In the absence of an application profile standard specifying otherwise: A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see Appendix B.4). A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. I think the text makes clear that an "application profile standard" can override the following requirements, but all those requirements do is require you to do things, so the only way to override the requirements is to *not* require you to do things. Even without the prefatory text, applications that use TLS could impose new requirements for the use of TLS with those applications.[0] WRT to the hypothetical example you propose: I think a WG specifying "TLS over X" could in fact make X25519 the requirement for "TLS over X" but not for TLS generally (this is the meaning of "application profile" in this context). Indeed, that's what the HTTP/2 example I gave does, except replacing TLS_RSA_WITH_AES_128_CBC_SHA with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for use with HTTP/2. I agree with you that the TLS WG possibly would not have agreed to change the MTI generally for TLS 1.2. In general, it's hard to change MTIs for existing protocols because that can put preexisting implementations in a state of noncompliance, albeit with the updated specification. However, that isn't a problem for new protocol X over TLS. Regardless, I don't think that the HTTP WG required the assent of the TLS WG specifically to require a new MTI for HTTP/2, as opposed to TLS 1.3 generally, which is what happened here. Rather, what was required was IETF Consensus, which gets judged at IETF LC. Of course, if the TLS WG was generally opposed, it is unlikely you would have IETF Consensus. However, as a practical matter there was significant overlap between the HTTP and TLS WGs and the selection of the new MTI cipher suite for HTTP/2 matched the direction the TLS WG was already going in for TLS 1.3. -Ekr [0] Even if I were to concede -- which I don't -- that profiles could only "narrow" or "constrain", it's not clear to me that that would preclude removing an MTI. After all, forbidding some non-MTI algorithm would be narrowing things, so I think it's a matter of interpretation whether removing an MTI would be narrowing things. On Thu, Nov 27, 2025 at 9:00 PM D. J. Bernstein <[email protected]> wrote: > Eric Rescorla writes: > > In this context I generally agree that "application profile" refers to > > an IETF standards track document describing the use of TLS with some > > other protocol. > > You're covering the words "application" and "standard", but there's a > further restriction from the word "profile", which (in a technical > context) refers specifically to _narrowing_ the allowed options. > > I haven't found any IETF documents telling the reader what the word > "profile" means, but looking around more widely I find definitions in > > > https://www.etsi.org/deliver/etsi_i_ets/300400_300499/300406/01_60/ets_300406e01p.pdf > > that match exactly my understanding of the word: "A base specification > is defined by opposition to a Profile, which constrains optionalities in > one or several base specifications." See the word "constrains"? > > For example, for TLS 1.3, a "profile" could prohibit X25519 (and X25519 > was ~0% of TLS key exchanges when RFC 8446 was written, unlike today's > ~90%), but it can't change the requirement to implement P-256. > > I've pointed out in the TLS WG that it would be good to move towards > fully eliminating P-256 (by first mandating X25519, then waiting for > more rollout to ensure interoperability, then deprecating P-256). Could > I just go to some random tiny WG instead and fund people there to issue > an "application profile standard" that replaces the P-256 requirement > with an X25519 requirement? The word "profile" says no. A "profile" can > only _narrow_ options. > > As another example, following the HTTP/2 "SHOULD NOT" that you quoted is > in violation of the TLS 1.2 _standard_. The people who wrote this HTTP/2 > "SHOULD NOT" screwed up in not going through proper procedures to update > TLS 1.2 for a different MTI---and I'm not actually sure they would have > reached TLS WG consensus for that! There was WG consensus to require ECC > in TLS 1.3; my impression is that part of what created this consensus > was that requiring ECC was specifically for TLS 1.3, while TLS 1.2 > implementors weren't forced to change anything. > > ---D. J. Bernstein > > > ===== NOTICES ===== > > This document may not be modified, and derivative works of it may not be > created, and it may not be published except as an Internet-Draft. (That > sentence is the official language from IETF's "Legend Instructions" for > the situation that "the Contributor does not wish to allow modifications > nor to allow publication as an RFC". I'm fine with redistribution of > copies of this document; the issue is with modification. Legend language > also appears in, e.g., RFC 5831. For further background on the relevant > IETF rules, see https://cr.yp.to/2025/20251024-rules.pdf.) > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
