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

[John Mattsson <[e-mail]>]

Hi,

My interpretation of the sentence “In the absence of an application profile standard specifying otherwise” in RFC 5246, RFC 8446, and 8446bis is that MTI requirements do not apply when an application profile standard is present. I also interpret this wording as allowing 3GPP to define such an application profile standard, which is clearly how 3GPP understands it as well.
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2279

I think it makes a lot of sense that 3GPP can forbid support of weak algorithms such as TLS_RSA_WITH_AES_128_CBC_SHA as soon as possible for them. I don't think it makes sense to force an application that only communicates with itself to support algorithms it will never use.

Cheers,
John

From: Eric Rescorla <[e-mail]>
Date: Thursday, 27 November 2025 at 23:37
To: Muhammad Usama Sardar <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)



On Thu, Nov 27, 2025 at 2:14 PM Muhammad Usama Sardar <[e-mail]<mailto:[e-mail]>> wrote:


Two concrete questions:

  1.  (trying to phrase my authority question more precisely) Is IETF the only body to define "application profile standard"? or do other SDOs count as "application profile standard" as well?

TBH, I think this is an undecided question. I think it's reasonably clear
that IETF Standards Track documents are in scope here, but IMO there
is at least a reasonable argument that standards from other SDO
would also apply. I don't recall this ever coming up, so I think people
are kind of left to interpret the text for themselves. If there was a need
for an authoritative statement from the IETF, I think we'd need to do
some kind of IETF consensus process, to, for instance, issue a liaison
statement (though see below).


  1.  Does it necessarily have to be standard track document?

I think the term "standard" here strongly suggests that the document
has to be Standards Track.

It's not clear to me what the practical impact of any of this really is.
The IETF doesn't have protocol police and won't do anything to you
if you violate some IETF standard. Sometimes those standards are
part of purchasing decisions and the like, but presumably if you
are buying an implementation of protocol X and X uses TLS but
overrides the TLS MTI, then you expect the behavior specified in
X, whether the resulting implementation violates the TLS spec or not.

-Ekr