If you interpret the word “standard” as defined in United Nations A-HRC-53-42,
"The term “standard” refers to an agreed norm defining a way of doing something in a repeatable manner." the current text is already very allowing. I don’t think any change is needed. Cheers, John Preuß Mattsson From: John Mattsson <[email protected]> Date: Saturday, 29 November 2025 at 09:53 To: Muhammad Usama Sardar <[email protected]>, Eric Rescorla <[email protected]>, [email protected] <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26) >Assuming this is somehow super important: To resolve this and move on (WGLC ended 2 days ago), IMHO we could possibly have a short draft defining "application profile standard" and clarifying how the WG interprets it and the caveats around that. I volunteer to create an initial draft based on what I understood from Ekr and John. That draft would probably save us all some time. I don’t think this discussion is directly related to draft-ietf-tls-mlkem — it’s fundamentally an RFC 8446 question. I am mostly fine with the existing text, “In the absence of an application profile standard specifying otherwise,” since this formulation works well for telecom SDOs such as 3GPP, GSMA, ETSI, ORAN, and others. If any changes are made, I would suggest removing the word “standard” in RFC 8446bis. Requiring IoT applications to support three signature algorithms (rsa_pkcs1_sha256, rsa_pss_rsae_sha256, and ecdsa_secp256r1_sha256) is not particularly constrained, and obligating IoT applications to go through a formal SDO and publish an application profile to avoid this requirement seems unnecessarily burdensome. Cheers, John Preuß Mattsson From: Muhammad Usama Sardar <[email protected]> Date: Saturday, 29 November 2025 at 00:31 To: Eric Rescorla <[email protected]>, [email protected] <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26) FWIW: Everything Ekr is saying below sounds reasonable to me. In particular, I also believe mixing and matching definitions from two very different SDOs can only lead to more ambiguities. Also, in the thread, Ekr has mentioned twice that MTI is not super important. I have some difficulty following D. J. Bernstein but as far as I understand, I haven't seen any clear response to that (sincere apologies if I have missed/misunderstood something). Assuming this is somehow super important: To resolve this and move on (WGLC ended 2 days ago), IMHO we could possibly have a short draft defining "application profile standard" and clarifying how the WG interprets it and the caveats around that. I volunteer to create an initial draft based on what I understood from Ekr and John. That draft would probably save us all some time. D. J. Bernstein, could you please clarify if that would address your concern? Appreciate a concise (ideally binary) answer. If not, could you please tell precisely and concisely what would address your concern? -Usama On 28.11.25 22:04, Eric Rescorla wrote: 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.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
