[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

[John Mattsson <[e-mail]>]

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 <john.mattsson=[e-mail]>
Date: Saturday, 29 November 2025 at 09:53
To: Muhammad Usama Sardar <[e-mail]>, Eric Rescorla <[e-mail]>, [e-mail] <[e-mail]>
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 <[e-mail]>
Date: Saturday, 29 November 2025 at 00:31
To: Eric Rescorla <[e-mail]>, [e-mail] <[e-mail]>
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.