Re: [TLS] Request mTLS Flag

Viktor Dukhovni writes: >On Fri, Nov 17, 2023 at 09:57:42AM +, Peter Gutmann wrote: >> Could this use/behaviour be referenced somewhere to provide guidance for >> implementers in general? It'd be good to have this made an official way to >> do >> things rather than just being done on an ad

Re: [TLS] Request mTLS Flag

On Fri, Nov 17, 2023 at 09:57:42AM +, Peter Gutmann wrote: > Viktor Dukhovni writes: > > >Indeed, Postfix 3.9 (release estimated Q1 '2024), when compiled against > >OpenSSL 3.2 (release estimated circa next week), will automatically signal > >client certificate types X.509(0) and RPK(2) iff

Re: [TLS] Request mTLS Flag

Viktor Dukhovni writes: >Indeed, Postfix 3.9 (release estimated Q1 '2024), when compiled against >OpenSSL 3.2 (release estimated circa next week), will automatically signal >client certificate types X.509(0) and RPK(2) iff and only a client >certificate is configured (available). Could this

Re: [TLS] Request mTLS Flag

On Thu, Nov 16, 2023 at 09:00:52PM +0200, Mohit Sethi wrote: > Unless I am mistaken, it has probably slipped under the radar of the > WG that this indication is already achievable by using the > client_certificate_type extension defined in RFC 7250: > https://datatracker.ietf.org/doc/html/rfc7250

Re: [TLS] Request mTLS Flag

Hi TLSWG, I have read draft-jhoyla-req-mtls-flag-00 and the ensuing mailing list discussion. I also watched the recording from IETF 118. I fully under the use-case where trusted client bots need a mechanism to indicate to the server that mutual certificate based authentication is desired.

Re: [TLS] Request mTLS Flag

On Tue, Nov 7, 2023 at 2:09 PM David Benjamin wrote: > It's a mess. Client certificates are the bane of my existence. :-) > It is really confusing, even for someone that knows more than most about this stuff. The parts that overlap for me are hardware keys (like a Yubikey or Google Advanced

Re: [TLS] Request mTLS Flag

I realized I used the word "context" in two different, uh, contexts, so that was probably very confusing. What I meant to say is that TLS client certificate decisions need to be remembered session-wide, for some appropriate notion of session. So browsing profile or something of that nature. But

Re: [TLS] Request mTLS Flag

On Tue, Nov 7, 2023 at 3:43 PM Ilari Liusvaara wrote: > On Mon, Oct 23, 2023 at 01:37:55PM -0400, Viktor Dukhovni wrote: > > > > - Some Java TLS libraries (used to?) fail the handshake when the > > client has no configured certs, or the list of issuer CA DN hints > > does include

Re: [TLS] Request mTLS Flag

On Mon, Oct 23, 2023 at 01:37:55PM -0400, Viktor Dukhovni wrote: > > - Some Java TLS libraries (used to?) fail the handshake when the > client has no configured certs, or the list of issuer CA DN hints > does include any of its available (typically just zero or one) >

Re: [TLS] Request mTLS Flag

On Mon, Oct 23, 2023 at 12:26:03PM -0400, David Benjamin wrote: > > So in my mind this is something that will (almost) never be sent by > browsers. > > What cases would the "(almost)" kick in? This extensions model just doesn't > match how client certificates work in browsers. I'm not seeing any

Re: [TLS] Request mTLS Flag

Hi all, The use case I suggested to David I think is the easiest to think of. I am happy for human users to access my website with no auth. I'm happy for bots that I approve of (e.g. search engine crawlers) to access my website. Bots that I have not approved (AI scrapers, scalpers, etc.) will be

Re: [TLS] Request mTLS Flag

On Mon, Oct 23, 2023 at 9:52 AM Jonathan Hoyland wrote: >> >> I'm not following how this identifies web crawlers, unless perhaps we're >> using the term to mean different things? I would expect web crawlers to >> typically not do much with client certificates, and to typically want to >>

Re: [TLS] Request mTLS Flag

On Mon, Oct 23, 2023 at 11:36:10AM -0400, David Benjamin wrote: > Would you expect a browser user to send this flag? On the browser side, we > don't know until the CertificateRequest whether a client certificate is > configured. We have to do a moderately expensive query, dependent on >

Re: [TLS] Request mTLS Flag

Hi David, On Mon, 23 Oct 2023, 17:26 David Benjamin, wrote: > > So in my mind this is something that will (almost) never be sent by > browsers. > > What cases would the "(almost)" kick in? This extensions model just > doesn't match how client certificates work in browsers. I'm not seeing any >

Re: [TLS] Request mTLS Flag

> So in my mind this is something that will (almost) never be sent by browsers. What cases would the "(almost)" kick in? This extensions model just doesn't match how client certificates work in browsers. I'm not seeing any interpretation beyond "always send" or "never send". > For example

Re: [TLS] Request mTLS Flag

Hi David, So in my mind this is something that will (almost) never be sent by browsers. This is aimed at bots, both internal and external. For example identifying a web crawler, and either allowing or disallowing it. Currently we identify many bots by IP range and user agent (and a bunch of

Re: [TLS] Request mTLS Flag

Would you expect a browser user to send this flag? On the browser side, we don't know until the CertificateRequest whether a client certificate is configured. We have to do a moderately expensive query, dependent on information on the CertificateRequest of the OS's cert and key stores to get this

[TLS] Request mTLS Flag

Hey TLSWG, I've just posted a new draft that defines a TLS Flag that provides a hint to the server that the client supports mTLS / is configured with a client