I'm with Richard on this one. Not a fan of the "mTLS" concept: it causes
confusion where customers ask whether "mTLS" is a different protocol or a
specific TLS implementation? However, it can be argued that this unfortunate
term has already taken root.
A UTA document discussing challenges of using TLS with client authentication
might be helpful, depending on the quality of the document.
Cheers,
Andrei
-----Original Message-----
From: Viktor Dukhovni <ietf-d...@dukhovni.org>
Sent: Wednesday, September 11, 2024 10:37 AM
To: tls@ietf.org
Subject: [EXTERNAL] [TLS] Re: Is there any interest in an RFC on how to do
cross-organization mTLS?
On Wed, Sep 11, 2024 at 10:24:06AM -0400, Richard Barnes wrote:
> In other words, I disagree with Olle's and John's assertion that
> there's no definition for mTLS. There is: "TLS where the server sends
> a CertificateRequest and the client sends a Certificate" Any TLS
> handshake where that happens is mutually authenticated.
>
> An RFC defining "mTLS" that adds a bunch of extra requirements on top
> of the above will just deepen the confusion. "In this scheme, we use
> mTLS between these two machines" ... "Oho, but you don't color the
> bits yellow and configure the PKI like RFC XXXX says you need to do for True
> mTLS".
Though one might reasonably argue that any post handshake authentication scheme
that performs channel binding is also "mTLS", and is often preferable
(sometimes in multiple ways). Sadly most post-handshake authentication
approaches do not perform channel binding.
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
