Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

Andrei Popov writes: >Yes, but, arguably, such broken clients won't be fixed by adding new >extensions/flags/etc. If they do not comply with the simple RFC language that >exists, can we expect them to implement the new flag correctly? I would argue that it's the server that's broken, not the cli

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

On Mon, Oct 23, 2023 at 05:49:47PM +, Andrei Popov wrote: > >> They could just proceed without a certificate, or return a default > one, but they don't. > > Yes, but, arguably, such broken clients won't be fixed by adding new > extensions/flags/etc. If they do not comply with the simple

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 >> index

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

On Sat, Oct 21, 2023 at 5:41 AM Ilari Liusvaara wrote: > On Fri, Oct 20, 2023 at 04:07:21PM -0400, David Benjamin wrote: > > On Thu, Oct 19, 2023 at 3:17 PM Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > - The multiple certificates from one ACME order really scares me. It > > >

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

On Mon, Oct 23, 2023 at 10:40 AM Andrei Popov wrote: > The use-case is not very clear to me: when is the decision whether to > authenticate a client or not based on the availability of a pre-configured > client certificate? > > If the client says they have a pre-configured cert, the server > auth

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

On Fri, Oct 20, 2023 at 2:15 PM Colm MacCárthaigh wrote: > This is very awesome. Just some quick thoughts: > > This extension seems very useful in internal environments with their > own proprietary PKI. The first bullet in the intro does get at this, > but I think it still undersells just how com

Re: [TLS] New Version Notification for draft-davidben-tls-trust-expr-00.txt

Quick update: we pushed a draft-01. It's basically the same, but we noticed we referred to the wrong name of some structs in places and figured it was worth a draft-01 to be less confusing. :-) On Thu, Oct 19, 2023 at 11:38 AM David Benjamin wrote: > Hi all, > > We just published a document on c

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

>> It would be useful to be able to request certificates conditioned on the >> client promising to not fail just because it is unable or unwilling to offer >> one. TLS RFCs do not require clients to fail the handshake when the server requests a cert and the client cannot satisfy the request. E.g

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

The use-case is not very clear to me: when is the decision whether to authenticate a client or not based on the availability of a pre-configured client certificate? If the client says they have a pre-configured cert, the server authenticates them; otherwise, the connection succeeds without clien

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 > informatio

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 > i

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 identif

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 ML),

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 i

[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 cert

[TLS] I-D Action: draft-ietf-tls-ctls-09.txt

Internet-Draft draft-ietf-tls-ctls-09.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Compact TLS 1.3 Authors: Eric Rescorla Richard Barnes Hannes Tschofenig Benjamin M. Schwartz Name:draft-ietf