+1 to Sean here, it would be easier to evaluate this with a document in hand. And in particular, a list of ways that people find mTLS is failing in practice.
I am generally skeptical of this idea, at least as a TLS WG item. In pure TLS terms, there is no such thing as "one-way TLS" or "mutually authenticated TLS" -- every TLS handshake supports both modes, and every TLS handshake could be mutually-authenticated until the server declines to send a CertificateRequest or the client declines to provide a Certificate in response. 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". If there's anything to be done here, it's recommendations for configuring TLS stacks to be compatible, probably largely focused on PKI considerations. Informational, not Proposed Standard; UTA, not TLS. And even then, we need a lot more precision on the problems to be solved. --Richard On Tue, Sep 10, 2024 at 11:21 AM Sean Turner <s...@sn3rd.com> wrote: > Mark, > > Hi! I’d suggest writing the I-D [1] and then we (the royal we here) can > figure out where it goes; could be ALLDISPATCH then TLS or UTA depending on > ALLDISPATCH outcome. Additionally, discussing at the ALLDISPATCH session > would get much a wider audience, which I think would help in general. > > spt > > [1] Submission deadline for IETF 121 is 21 October. > > > On Sep 9, 2024, at 14:42, Mark Robinson <m...@markrobinson.io> wrote: > > > > I've been doing a lot of work lately to support organizations that do > mTLS between each other. The problem I've found is that there is a huge > amount of ignorance on TLS in general and mTLS in particular. > > > > Would it be appropriate to write an RFC on how to make > cross-organization mTLS work reliably and at scale? Would this > group/mailing list be the right people to work with to make that happen? > > > > Mark > > _______________________________________________ > > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
