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

[Muhammad Usama Sardar <[e-mail]>]

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.
>