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 <[email protected]> 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 <[email protected]> > *Date: *Thursday, 27 November 2025 at 23:37 > *To: *Muhammad Usama Sardar <[email protected]> > *Cc: *[email protected] <[email protected]> > *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 < > [email protected]> 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 > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
