In this context I generally agree that "application profile" refers to
an IETF standards track document describing the use of TLS with some
other protocol.
If I understand correctly, you're arguing that a profile couldn't
remove an MTI requirement or substitute a different MTI. I think the
text of RFC 8446 fairly clearly indicates otherwise:
In the absence of an application profile standard specifying
otherwise:
...
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].
This text doesn't come with any restrictions on what an application
profile can do, so I think the best interpretation is that it can
modify, replace, or remove any of these requirements. As a concrete
example, RFC 9113 (HTTP/2) explicitly overrides the RFC 5246 MTIs in
Section 9.2.2:
A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the
prohibited cipher suites listed in Appendix A.
...
The list of prohibited cipher suites includes the cipher suite that
TLS 1.2 makes mandatory, which means that TLS 1.2 deployments could
have non-intersecting sets of permitted cipher suites. To avoid this
problem, which causes TLS handshake failures, deployments of HTTP/2
that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[TLS-ECDHE] with the P-256 elliptic curve [RFC8422].
Moreover, this interpretation makes sense in the context of
interoperability, which is mostly between TLS-using applications, not
between TLS implementations in a vacuum. As long as the application
profile provides an adequate set of MTIs, then application
implementations will be able to successfully interoperate.
-Ekr
On Thu, Nov 27, 2025 at 11:45 AM D. J. Bernstein <[email protected]> wrote:
> Trimming to [email protected] since the last-call period has ended.
>
> Muhammad Usama Sardar writes:
> > If any one can write such profiles, then the whole idea of MTI
> > becomes questionable to me. That is, I could write my own profile and
> say I
> > am still compliant with RFC 8446.
>
> Indeed, such permission wouldn't make any sense. MTI requirements are
> critical protocol requirements for ensuring interoperability, so I'm
> baffled at the idea that implementors are allowed to ignore them. (Would
> the TLS-LTS "profile" become part of IETF's TLS if the author sticks the
> word "standard" on top of the document and posts the result somewhere?)
>
> Pasi Eronen explained the actual intent of the wording on list in 2006:
> "The 'application profile specifications' mentioned in Sections 5.2 and
> 5.4 were intended to specify how to *use* the RFC4279 ciphersuites to
> secure some particular application/service/higher-layer-protocol,
> without modifying anything in TLS. (In other words, something like RFC
> 2818 or 4261, which are for certificate-based ciphersuites)"
>
> This doesn't directly answer your question about authority (I would
> think that the word "standard" in an RFC means "IETF standard" when the
> text doesn't explicitly allow non-IETF standards), but "use ... without
> modifying anything in TLS" says that this is making selections _within_
> the allowed options, not making exceptions.
>
> To me this is what the word "profile" means in a technical context, so I
> don't agree that a more permissive notion matches the text of RFC 8446.
>
> ---D. J. Bernstein
>
>
> ===== NOTICES =====
>
> This document may not be modified, and derivative works of it may not be
> created, and it may not be published except as an Internet-Draft. (That
> sentence is the official language from IETF's "Legend Instructions" for
> the situation that "the Contributor does not wish to allow modifications
> nor to allow publication as an RFC". I'm fine with redistribution of
> copies of this document; the issue is with modification. Legend language
> also appears in, e.g., RFC 5831. For further background on the relevant
> IETF rules, see https://cr.yp.to/2025/20251024-rules.pdf.)
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
