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

[Eric Rescorla <[e-mail]>]

I think this is a reasonable substantive position and a not unreasonable
interpretation of the text.

I think it's also possible to interpret the text another way, but as I
said, I don't think it matters that much.

-Ekr



On Fri, Nov 28, 2025 at 4:05 AM John Mattsson <[e-mail]>
wrote:

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