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

2023-10-23 Thread Peter Gutmann 
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 client.  An awful
lot of (non-WWW) servers automatically request a client cert without anyone
running the server being aware of it, or when asked, how to disable it.  The
clients then sleepwalk their way past it with a zero-length reply and things
continue as normal with neither the server admin nor the client-side user
being aware that certificate auth was requested and denied.

At least as a client, you can't read anything into seeing a cert request from
the server, it's just a standard part of the handshake, like a keyex or a
finished.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-10-23 Thread Viktor Dukhovni 
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 RFC
> language that exists, can we expect them to implement the new flag
> correctly?

You misunderstood.  If they don't send the flag, the servers in question
simply won't request certificates.  Requests will only when when the
cert request is *explicitly*  solicited.  So the broken clients *will*
be fixed by (lack of) the extension.

--
VIktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Request mTLS Flag

2023-10-23 Thread Jonathan Hoyland 
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 subject
to more intense scrutiny.

I think the key factor here is that, if I am happy that I can distinguish
between human and bot activity sufficiently well already, then this lets me
distinguish between bots that I approve of and bots I don't approve of or
don't know.
The current situation is something like:

There is a bot that says "My IP range is any AWS IP, and I set my
user-agent to 'Good Bot'".
Other (potentially malicious) bots can impersonate that bot fairly easily.

If a bot connects to my server from an AWS IP and has a user-agent set to
'Good Bot' I have to apply just as much scrutiny as I would have to apply
to any other bot.
Further, if I start getting a large DoS attack from those IPs and with that
user agent then I might have to just block all traffic with that signature,
even though that will hurt the good bot, whose traffic I want.

However, if the bot has a valid certificate that's in my trust chain
(however I decide to configure that), then I can distinguish easily between
the imposters and the real deal, and I can block the imposters without
collateral damage.

If your client is a large scale automated bot (as opposed to a browser)
that always has the same certificate configured (as an example, obviously
other setups can exist) then it should expect to always send this flag.

A malicious bot could send this flag, but wouldn't be able to complete the
handshake with an approved certificate.
They could send an unknown certificate, but the server wouldn't necessarily
accept it.

Bots that can dynamically select a certificate should probably not set this
flag IMO, as there are other mechanisms available if client auth is
necessary, inc. PHA or EAs.
This flag is simply a hint that we are on the happy path.

@Watson

So I think UpA works well for its intended use case, namely authenticating
a single browser-based session, but when we tried to implement it for a
bots use case it rapidly became difficult to implement because of the tight
binding required between the TLS and HTTP layers, which many languages and
libraries intentionally isolate from one another, to enable things like
connection pooling.
I am very keen to see the UpA work move forward in parallel to this,
although if someone smarter than me can get UpA working in this case too
then I'd be happy to focus there.

However a side-goal of this work is to help get the TLS Flags work over the
line, so even if we can make UpA work here I think there is some value to
this work stream.

Regards,

Jonathan




On Mon, 23 Oct 2023 at 22:22, Watson Ladd  wrote:

> 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 the web in the same way that humans with web browsers see it.
> >
> >
> > So typically web crawlers don't use mTLS, they rely on things like
> publishing their IP range for auth, which isn't a great signal.
> >
> > If we could reliably identify e.g. GoogleBot then we could skip some of
> our bot detection systems for definitely-allowed traffic, allowing us to be
> stricter with unknown traffic, or of course, explicitly-disallowed traffic.
> >
> > There is an argument that one could show bots different results to
> humans, but given that this is explicitly aimed at bots that we approve, I
> don't see the incentive. Maybe improved TTFB or something?
>
> Would unprompted auth in the HTTP working group be adaptable to this?
>
> Sincerely,
> Watson
>
>
>
> --
> Astra mortemque praestare gradatim
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Request mTLS Flag

2023-10-23 Thread Watson Ladd 
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 the web in the same way that humans with web browsers see it.
>
>
> So typically web crawlers don't use mTLS, they rely on things like publishing 
> their IP range for auth, which isn't a great signal.
>
> If we could reliably identify e.g. GoogleBot then we could skip some of our 
> bot detection systems for definitely-allowed traffic, allowing us to be 
> stricter with unknown traffic, or of course, explicitly-disallowed traffic.
>
> There is an argument that one could show bots different results to humans, 
> but given that this is explicitly aimed at bots that we approve, I don't see 
> the incentive. Maybe improved TTFB or something?

Would unprompted auth in the HTTP working group be adaptable to this?

Sincerely,
Watson



-- 
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-10-23 Thread David Benjamin 
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
> > >   seems to me that can lead to all sorts of trouble.
> > >
> >
> > Certainly open to different mechanisms, though could you elaborate on
> > the trouble? We started with this one because it's actually just fixing a
> > mechanism ACME *already has*. RFC 8555, 7.4.2 has this bit:
> >
> >The server MAY provide one or more link relation header fields
> >[RFC8288] with relation "alternate".  Each such field SHOULD express
> >an alternative certificate chain starting with the same end-entity
> >certificate.  This can be used to express paths to various trust
> >anchors.  Clients can fetch these alternates and use their own
> >heuristics to decide which is optimal.
>
> Note the part "the same end-entity certificate.". The way I interpretted
> the draft, returning different end-entity certificates would be allowed.
>
>
> > Whether anyone has ever used this, I don't know. The "and use their own
> > heuristics to decide which is optimal" bit is quite absurd. :-) Relative
> to
> > that, all we've done is:
>
> Yes, that gets sometimes used.
>
>
> > But I suspect we'll want to define one where you make multiple orders
> too.
> > That would probably work better for, e.g., Merkle Tree certs where the
> two
> > issuances complete at very different times. But then, conversely, when
> the
> > two paths actually share an end-entity certificate, I imagine a single
> > order would be better so the CA knows it only needs to generate one
> > signature. And then when they don't share an end-entity certificate but
> are
> > similar enough in lifetime and issuance time, either seems fine, so we
> > figured this was a reasonable starting point.
>
> Well, I do not think it is feasible to use the normal ACME issuance
> mechanism for Merkle Tree certificates. The issuance is just too slow.
>
> And things like ACME ARI (which is required for actually handling
> revocations) inherently assume each order can only result one
> certificate.
>

The note about sharing an EE cert is just a SHOULD, not a MUST. RFC 8555
doesn't say why, but our interpretation was, like you note, this was mostly
a concern for things like accounting for renewals and revocations. We tried
to firm that up a bit by saying this makes sense when you're willing to
issue and renew all the variants together. For something like ARI, I was
imagining the ACME client would just check all of them (we're already
assuming the ACME client has been updated) and, if it needs to renew any of
them, it goes ahead and renews all of them. Slightly wasteful if renewal
was triggered by one of them getting revoked, rather than them all expiring
together. But I expect that's not common enough to be worth optimizing for.

Do you think multiple orders would be better? A multi-order flow is
probably more complex than fits in this document (this ACME change is
pretty small), so we didn't start with it. Plus this initial version seemed
natural to us based on what ACME had already defined. But we're much more
interested in making this kind of multi-certificate deployment model
possible than any of the particular details. Happy to adjust things based
on what turns out to work best. (One nuisance with a multi-order flow is
that the CA will have a harder time linking the requests together, which
opens a can of worms around whether they do separate validations or not.)



> > > - If there can be only one certificate, one could send all the chains
> > >   in one go via fist sending the certificate, then issuer chains each
> > >   ended by entry describing the trust anchor.
> > >
> >
> > I'm not quite sure if I've parsed this right, but are you thinking of one
> > file that somehow describes all alternatives together? That's plausible
> > too. Like I said, we mostly did this one because ACME already did it, so
> we
> > inferred that was The ACME Way. :-)
>
> Yes, one file describing all alternatives together. I think that is
> easier to work with than the existing alternatives mechanism (I don't
> think most clients even support that).
>

I think having to do a round of updating existing clients is fine here.
We'd already need to teach them to implement this thing. But if we think
putting them in one bundle is more convenient, that's fine by me too. I
don't actually care.

Exploring that direction a bit, won't that make issues around ARI and
different issuance rates worse? Bundling them means the system is further
inclined to treat them as one unit, but a lot of these problems come from
wanting to be able to treat each path separately, be it different renewal
times, different issuance times, potentially even different private keys
associated, etc. I also worry it'll get a bit thorny as

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

2023-10-23 Thread Rob Sayre 
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
> authenticates them; otherwise, the connection succeeds without client auth
> (and, presumably, the server returns a different response at the
> application layer)?
>

It looked to me like it's intended for mTLS behind a front-end server, not
really the open internet. But, the draft is very brief and I'm not sure.
Something like this: 

So, if you're operating a front-end server, you might not require a client
certificate from external clients, but you would for the internal clients.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-10-23 Thread David Benjamin 
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 compelling this extension
> would be. FSIs/Banks, Governments, technology companies often have CAs
> with validities in short durations and have to perform rotations very
> often. This extension makes that so much more manageable and safer.  I
> think there's a strong internet stability argument here ... many large
> outages of organizations have been caused by mishandling these
> rotations.
>

Yeah, my colleagues on the server end have had their share of nightmares
dealing with certificate transitions on Google properties. We like to talk
about PKIs as if they're these big, consistent things, but once you
actually get down to it, this fiction breaks down very fast. Relying
parties vary a bit, and we should take that into account when designing
systems.


> In the security / privacy considerations:   1.  Since this extension
> can appear in the CH in the clear, should we consider the case where
> network operators may use it to "enforce" support of particular trust
> anchors? For example, a firewall may reject connections based on
> anchors that do or don't support.  and 2. Is this another fingerprint,
> at least at system level?  For example; corporate user's whose
> organizations who add their own TAs may become finger-printable as
> coming from those organizations.
>

Re (2), section 10 talks about this. It's hard to avoid saying what CAs you
trust without, well, saying what CAs you trust. Which means you should only
use this in contexts where you're willing to do that. For something like a
web browser, I would expect that we'd by default only advertise the
browser-vendor-managed roots. That only reveals what browser you're
running, which is thoroughly revealed by the entire web. That does
unfortunately leave browser-adjacent private PKIs in the fallback path, and
so servers still need to divine which to use. It's no worse than the status
quo, but it is a bit disappointing to leave that problem unsolved.

One could imagine an enterprise policy for administrators to say "yes, I
want robust negotiation and am willing to reveal this part of my clients'
trust anchor list". Or perhaps one filtered down to a particular set of
name patterns that will stay within an intranet? I dunno. One way or
another though, I think this is kinda fundamental to trying to help the
server pick certificates, at least for any solution that looks like the
standard client-offer / server-select TLS flow. (I could imagine
alternative solutions with different tradeoffs, like the server presenting
a list and the client picking, though that will add different complications
such as extra round-trips or dependency on a DNS record that may not be as
accessible. But I think any solution like that should be separate work. If
we find we need a couple of these, it's more moving parts, but there's no
reason they can't coexist.)

Re (1), I think this mostly falls out of (2) and where you try to use this.
We're scoping this to the subset of your trust anchor list that you
*are* willing
to reveal. In the browser-vendor-managed roots case, this ultimately just
reveals what browser or browser family you are (which is already thoroughly
revealed for better or worse). I won't speculate on what misguided network
operators may try to filter on, but it wouldn't be a new capability. Happy
to take a PR to add some extra text if you think it's worth talking about
though.

Additionally, any aspect of your trust anchor list that isn't revealed
won't be affected. Ultimately, this doesn't change what the relying party
*actually* accepts. This just allows the relying party to communicate
something about it (just like, but more compactly than, the existing
certificate_authorites extension) in hopes of better navigating this mess
of sometimes overlapping but ultimately disparate PKIs.


> Why sort TrustStores first by name-length, and then lexicographically?
> Just seems a little unnecessarily complex and unfriendly to indices.
>

Do you mean in section 5.1? It was just arbitrary. I wasn't sure if
"lexicographically", in IETF documents, was canonically defined to be
length first or "a" before "ab" before "b". (Wikipedia seems to suggest
there are variants
.)
So I just picked a disambiguation that didn't take very many words to say.
:-)

But I'm fine with whatever order. The goal was to just pick *some* defined
sort order, so that it's easy to find

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

2023-10-23 Thread David Benjamin 
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 certificate negotiation. It's a TLS
> extension, which allows the client to communicate which trust anchors it
> supports, primarily focused on use cases like the Web PKI where trust
> stores are fairly large. There is also a supporting ACME extension, to
> allow CAs to provision multiple certificate chains on a server, with enough
> metadata to match against what the client sends. (It also works in the
> other direction for client certificates.)
>
> The hope is this can build towards a more agile and flexible PKI. In
> particular, the Use Cases section of the document details some scenarios
> (e.g. root rotation) that can be made much more robust with it.
>
> It's very much a draft-00, but we're eager to hear your thoughts on it!
>
> David, Devon, and Bob
>
> -- Forwarded message -
> From: 
> Date: Thu, Oct 19, 2023 at 11:36 AM
> Subject: New Version Notification for draft-davidben-tls-trust-expr-00.txt
> To: Bob Beck , David Benjamin ,
> Devon O'Brien 
>
>
> A new version of Internet-Draft draft-davidben-tls-trust-expr-00.txt has
> been
> successfully submitted by David Benjamin and posted to the
> IETF repository.
>
> Name: draft-davidben-tls-trust-expr
> Revision: 00
> Title:TLS Trust Expressions
> Date: 2023-10-19
> Group:Individual Submission
> Pages:35
> URL:
> https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/
> HTML:
> https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr
>
>
> Abstract:
>
>This document defines TLS trust expressions, a mechanism for relying
>parties to succinctly convey trusted certification authorities to
>subscribers by referencing named and versioned trust stores.  It also
>defines supporting mechanisms for subscribers to evaluate these trust
>expressions, and select one of several available certification paths
>to present.  This enables a multi-certificate deployment model, for a
>more agile and flexible PKI that can better meet security
>requirements.
>
>
>
> The IETF Secretariat
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-10-23 Thread Andrei Popov 
>> 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., TLS 1.3 says:

" If the server requests client authentication but no
   suitable certificate is available, the client MUST send a Certificate
   message containing no certificates (i.e., with the "certificate_list"
   field having length 0)."

>> 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 RFC language that 
exists, can we expect them to implement the new flag correctly?

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Viktor Dukhovni
Sent: Monday, October 23, 2023 10:38 AM
To: tls@ietf.org
Subject: [EXTERNAL] 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 information on the CertificateRequest of the OS's cert
> and key stores to get this information. This query may even call into
> things like 3p smartcard drivers, which may do arbitrarily disruptive
> things like showing UI.

One sensible use-case for such a signal is in mail user agent (MUA) to mail 
submission agent (MSA) communication.

- When the submission client is a bot, a client cert is a fairly
  natural choice of credential.

- 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)
  certificates.

  They could just proceed without a certificate, or return a default
  one, but they don't.

- Most MTAs and MSAs don't request certificates, avoiding the
  potential interoperability issue.

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.

Hence, I would like to see this flag move forward, though I'd also, perhaps 
separately, like to see an extension, that either combined with this flag, or 
alone, conveys an additional DNS name, where the server might find the client's 
TLSA records, allowing the client to establish a binding to that name.  
Something like, given:

_smtp-client.example.com. IN TLSA 3 1 1 ...

send a hint of "example.com", with the "_smtp-client" prefix implied by the 
application protocol (prepended by the server).

https://datatracker.ietf.org/doc/html/draft-huque-tls-dane-clientid

--
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-10-23 Thread Andrei Popov 
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 client auth (and, presumably, 
the server returns a different response at the application layer)?

The draft says:
>>Sometimes a server does not want to negotiate mTLS with every client, but 
>>might wish to authenticate a subset of them.
Yes, there are a number of scenarios of this nature, but in the use-cases I’ve 
seen, the decision is made post-handshake, based on what happens at the 
application layer. Something like a public landing page with some protected 
links that require client auth if the user chooses them.

From a TLS client’s perspective, let’s say the client certificate is 
preconfigured. Before receiving a CertificateRequest, the TLS client does not 
know whether the preconfigured cert even satisfies the request. The client 
could be coded to go look for a better-matching cert, based on the 
CertificateRequest.

>>This is aimed at bots, both internal and external. For example identifying a 
>>web crawler, and either allowing or disallowing it.
As soon as servers start rejecting bots based on the absence of this flag, 
won’t bots figure out to send the flag?

>>If the server unexpectedly requests a certificate from a human user, most 
>>users wouldn’t know what to do.
Sure, but there also bots that can select a certificate dynamically in response 
to a CertificateRequest. Should they send this proposed flag or no?

Cheers,

Andrei

From: TLS  On Behalf Of David Benjamin
Sent: Monday, October 23, 2023 9:26 AM
To: Jonathan Hoyland 
Cc:  
Subject: [EXTERNAL] 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 identifying a web crawler, and either allowing or disallowing it.

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 the web in the 
same way that humans with web browsers see it.

> I don't think this leaks more info than a dedicated endpoint (even accounting 
> for ECH), and from a security perspective is just a hint.

The difference is the dedicated endpoint case only kicks in once you are 
actually talking to a site that is deployed that way. A ClientHello flag would 
likely be sent unconditionally, because it's too early to condition it on much.

On Mon, Oct 23, 2023 at 11:58 AM Jonathan Hoyland 
mailto:jonathan.hoyl...@gmail.com>> wrote:
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), 
which isn't always reliable.

The web crawler case is where the dedicated endpoint falls over, because 
crawlers are indexing the human visible web.

I don't think this leaks more info than a dedicated endpoint (even accounting 
for ECH), and from a security perspective is just a hint.


Regards,

Jonathan

On Mon, 23 Oct 2023, 16:36 David Benjamin, 
mailto:david...@chromium.org>> 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 
information on the CertificateRequest of the OS's cert and key stores to get 
this information. This query may even call into things like 3p smartcard 
drivers, which may do arbitrarily disruptive things like showing UI.

And if we could somehow predict this information, this would leak into the 
cleartext ClientHello when, starting TLS 1.3, the whole client certificate flow 
is in the encrypted portion of the handshake.

So, practically speaking, I don't think browsers could do anything meaningful 
with this extension. We'd either always send it, on grounds that we have code 
to rummage for client certs on request, or never send it on grounds that we're 
not preconfigured with a client cert at the time of ClientHello. Either way, it 
seems likely to interfere with someone's assumptions here.

The dedicated endpoint strategy seems more straightforward.

David

On Mon, Oct 23, 2023, 11:22 Jonathan Hoyland 
mailto:jonathan.hoyl...@gmail.com>> wrote:

Hey TLSWG,


I've just posted a new 
draft that 
defines a TLS

Re: [TLS] Request mTLS Flag

2023-10-23 Thread Viktor Dukhovni 
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
> information on the CertificateRequest of the OS's cert and key stores to
> get this information. This query may even call into things like 3p
> smartcard drivers, which may do arbitrarily disruptive things like showing
> UI.

One sensible use-case for such a signal is in mail user agent (MUA) to
mail submission agent (MSA) communication.

- When the submission client is a bot, a client cert is a fairly
  natural choice of credential.

- 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)
  certificates.

  They could just proceed without a certificate, or return a default
  one, but they don't.

- Most MTAs and MSAs don't request certificates, avoiding the
  potential interoperability issue.

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.

Hence, I would like to see this flag move forward, though I'd also,
perhaps separately, like to see an extension, that either combined with
this flag, or alone, conveys an additional DNS name, where the server
might find the client's TLSA records, allowing the client to establish
a binding to that name.  Something like, given:

_smtp-client.example.com. IN TLSA 3 1 1 ...

send a hint of "example.com", with the "_smtp-client" prefix implied by
the application protocol (prepended by the server).

https://datatracker.ietf.org/doc/html/draft-huque-tls-dane-clientid

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Request mTLS Flag

2023-10-23 Thread Jonathan Hoyland 
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
> interpretation beyond "always send" or "never send".
>

So I was thinking about a case where you're behind some TLS terminating
proxy. Assuming the proxy requires mTLS for every connection and the
middlebox wants to treat misconfigured boxes differently, maybe you would
use something like this.
I would have said never,  but never say never, right?

>
> > For example identifying a web crawler, and either allowing or
> disallowing it.
>
> 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 the web in the same way that humans with web browsers see it.
>

So typically web crawlers don't use mTLS, they rely on things like
publishing their IP range for auth, which isn't a great signal.

If we could reliably identify e.g. GoogleBot then we could skip some of our
bot detection systems for definitely-allowed traffic, allowing us to be
stricter with unknown traffic, or of course, explicitly-disallowed traffic.

There is an argument that one could show bots different results to humans,
but given that this is explicitly aimed at bots that we approve, I don't
see the incentive. Maybe improved TTFB or something?


> > I don't think this leaks more info than a dedicated endpoint (even
> accounting for ECH), and from a security perspective is just a hint.
>
> The difference is the dedicated endpoint case only kicks in once you are
> actually talking to a site that is deployed that way. A ClientHello flag
> would likely be sent unconditionally, because it's too early to condition
> it on much.
>

So in my mind this is sent by a bot that is crawling the entire web. It's
automated (as opposed to human triggered), and this is an optional hint, so
it doesn't matter if there's a privacy leak in that way. (Although that's
an interesting thought, do bots have a need for privacy?)

Regards,

Jonathan



> On Mon, Oct 23, 2023 at 11:58 AM Jonathan Hoyland <
> jonathan.hoyl...@gmail.com> wrote:
>
>> 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), which isn't always reliable.
>>
>> The web crawler case is where the dedicated endpoint falls over, because
>> crawlers are indexing the human visible web.
>>
>> I don't think this leaks more info than a dedicated endpoint (even
>> accounting for ECH), and from a security perspective is just a hint.
>>
>>
>> Regards,
>>
>> Jonathan
>>
>>
>> On Mon, 23 Oct 2023, 16:36 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
>>> information on the CertificateRequest of the OS's cert and key stores to
>>> get this information. This query may even call into things like 3p
>>> smartcard drivers, which may do arbitrarily disruptive things like showing
>>> UI.
>>>
>>> And if we could somehow predict this information, this would leak into
>>> the cleartext ClientHello when, starting TLS 1.3, the whole client
>>> certificate flow is in the encrypted portion of the handshake.
>>>
>>> So, practically speaking, I don't think browsers could do anything
>>> meaningful with this extension. We'd either always send it, on grounds that
>>> we have code to rummage for client certs on request, or never send it on
>>> grounds that we're not preconfigured with a client cert at the time of
>>> ClientHello. Either way, it seems likely to interfere with someone's
>>> assumptions here.
>>>
>>> The dedicated endpoint strategy seems more straightforward.
>>>
>>> David
>>>
>>>
>>> On Mon, Oct 23, 2023, 11:22 Jonathan Hoyland 
>>> wrote:
>>>
 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 certificate.

 Usually the server has no way to know in advance whether a given
 inbound connection is from a client with a certificate. If the server
 unexpectedly requests a certificate from a human user, most users wouldn’t
 know what to do. To avoid this many servers never send the

Re: [TLS] Request mTLS Flag

2023-10-23 Thread David Benjamin 
> 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 identifying a web crawler, and either allowing or disallowing
it.

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 the web in the same way that humans with web browsers see it.

> I don't think this leaks more info than a dedicated endpoint (even
accounting for ECH), and from a security perspective is just a hint.

The difference is the dedicated endpoint case only kicks in once you are
actually talking to a site that is deployed that way. A ClientHello flag
would likely be sent unconditionally, because it's too early to condition
it on much.

On Mon, Oct 23, 2023 at 11:58 AM Jonathan Hoyland <
jonathan.hoyl...@gmail.com> wrote:

> 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), which isn't always reliable.
>
> The web crawler case is where the dedicated endpoint falls over, because
> crawlers are indexing the human visible web.
>
> I don't think this leaks more info than a dedicated endpoint (even
> accounting for ECH), and from a security perspective is just a hint.
>
>
> Regards,
>
> Jonathan
>
>
> On Mon, 23 Oct 2023, 16:36 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
>> information on the CertificateRequest of the OS's cert and key stores to
>> get this information. This query may even call into things like 3p
>> smartcard drivers, which may do arbitrarily disruptive things like showing
>> UI.
>>
>> And if we could somehow predict this information, this would leak into
>> the cleartext ClientHello when, starting TLS 1.3, the whole client
>> certificate flow is in the encrypted portion of the handshake.
>>
>> So, practically speaking, I don't think browsers could do anything
>> meaningful with this extension. We'd either always send it, on grounds that
>> we have code to rummage for client certs on request, or never send it on
>> grounds that we're not preconfigured with a client cert at the time of
>> ClientHello. Either way, it seems likely to interfere with someone's
>> assumptions here.
>>
>> The dedicated endpoint strategy seems more straightforward.
>>
>> David
>>
>>
>> On Mon, Oct 23, 2023, 11:22 Jonathan Hoyland 
>> wrote:
>>
>>> 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 certificate.
>>>
>>> Usually the server has no way to know in advance whether a given inbound
>>> connection is from a client with a certificate. If the server unexpectedly
>>> requests a certificate from a human user, most users wouldn’t know what to
>>> do. To avoid this many servers never send the CertificateRequest message in
>>> the server’s first flight, or set up dedicated endpoints used only by bots.
>>> If client authentication is necessary it can be negotiated later using a
>>> higher layer either through post-handshake auth or with an Exported
>>> Authenticator, but both of those options add round trips to the connection.
>>>
>>> At Cloudflare we’re exploring ways to quickly identify clients. Having
>>> an explicit signal from the client that it has an mTLS certificate on offer
>>> reduces round-trips to find out, avoids unnecessarily probing clients that
>>> have no certificate, etc. I think this would be an ideal use case for the
>>> TLS Flags extension.
>>>
>>> I have a pair of interoperable implementations (one based on boringssl
>>> and one based on Go TLS) which I plan to open source before Prague.
>>> Obviously these include implementations of the TLS Flags extension, which
>>> hopefully will help drive that work forward too.
>>>
>>> Regards,
>>>
>>> Jonathan
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Request mTLS Flag

2023-10-23 Thread Jonathan Hoyland 
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), which isn't always reliable.

The web crawler case is where the dedicated endpoint falls over, because
crawlers are indexing the human visible web.

I don't think this leaks more info than a dedicated endpoint (even
accounting for ECH), and from a security perspective is just a hint.


Regards,

Jonathan


On Mon, 23 Oct 2023, 16:36 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
> information on the CertificateRequest of the OS's cert and key stores to
> get this information. This query may even call into things like 3p
> smartcard drivers, which may do arbitrarily disruptive things like showing
> UI.
>
> And if we could somehow predict this information, this would leak into the
> cleartext ClientHello when, starting TLS 1.3, the whole client certificate
> flow is in the encrypted portion of the handshake.
>
> So, practically speaking, I don't think browsers could do anything
> meaningful with this extension. We'd either always send it, on grounds that
> we have code to rummage for client certs on request, or never send it on
> grounds that we're not preconfigured with a client cert at the time of
> ClientHello. Either way, it seems likely to interfere with someone's
> assumptions here.
>
> The dedicated endpoint strategy seems more straightforward.
>
> David
>
>
> On Mon, Oct 23, 2023, 11:22 Jonathan Hoyland 
> wrote:
>
>> 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 certificate.
>>
>> Usually the server has no way to know in advance whether a given inbound
>> connection is from a client with a certificate. If the server unexpectedly
>> requests a certificate from a human user, most users wouldn’t know what to
>> do. To avoid this many servers never send the CertificateRequest message in
>> the server’s first flight, or set up dedicated endpoints used only by bots.
>> If client authentication is necessary it can be negotiated later using a
>> higher layer either through post-handshake auth or with an Exported
>> Authenticator, but both of those options add round trips to the connection.
>>
>> At Cloudflare we’re exploring ways to quickly identify clients. Having an
>> explicit signal from the client that it has an mTLS certificate on offer
>> reduces round-trips to find out, avoids unnecessarily probing clients that
>> have no certificate, etc. I think this would be an ideal use case for the
>> TLS Flags extension.
>>
>> I have a pair of interoperable implementations (one based on boringssl
>> and one based on Go TLS) which I plan to open source before Prague.
>> Obviously these include implementations of the TLS Flags extension, which
>> hopefully will help drive that work forward too.
>>
>> Regards,
>>
>> Jonathan
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Request mTLS Flag

2023-10-23 Thread David Benjamin 
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 information. This query may even call into things like 3p
smartcard drivers, which may do arbitrarily disruptive things like showing
UI.

And if we could somehow predict this information, this would leak into the
cleartext ClientHello when, starting TLS 1.3, the whole client certificate
flow is in the encrypted portion of the handshake.

So, practically speaking, I don't think browsers could do anything
meaningful with this extension. We'd either always send it, on grounds that
we have code to rummage for client certs on request, or never send it on
grounds that we're not preconfigured with a client cert at the time of
ClientHello. Either way, it seems likely to interfere with someone's
assumptions here.

The dedicated endpoint strategy seems more straightforward.

David


On Mon, Oct 23, 2023, 11:22 Jonathan Hoyland 
wrote:

> 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 certificate.
>
> Usually the server has no way to know in advance whether a given inbound
> connection is from a client with a certificate. If the server unexpectedly
> requests a certificate from a human user, most users wouldn’t know what to
> do. To avoid this many servers never send the CertificateRequest message in
> the server’s first flight, or set up dedicated endpoints used only by bots.
> If client authentication is necessary it can be negotiated later using a
> higher layer either through post-handshake auth or with an Exported
> Authenticator, but both of those options add round trips to the connection.
>
> At Cloudflare we’re exploring ways to quickly identify clients. Having an
> explicit signal from the client that it has an mTLS certificate on offer
> reduces round-trips to find out, avoids unnecessarily probing clients that
> have no certificate, etc. I think this would be an ideal use case for the
> TLS Flags extension.
>
> I have a pair of interoperable implementations (one based on boringssl and
> one based on Go TLS) which I plan to open source before Prague. Obviously
> these include implementations of the TLS Flags extension, which hopefully
> will help drive that work forward too.
>
> Regards,
>
> Jonathan
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Request mTLS Flag

2023-10-23 Thread Jonathan Hoyland 
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 certificate.

Usually the server has no way to know in advance whether a given inbound
connection is from a client with a certificate. If the server unexpectedly
requests a certificate from a human user, most users wouldn’t know what to
do. To avoid this many servers never send the CertificateRequest message in
the server’s first flight, or set up dedicated endpoints used only by bots.
If client authentication is necessary it can be negotiated later using a
higher layer either through post-handshake auth or with an Exported
Authenticator, but both of those options add round trips to the connection.

At Cloudflare we’re exploring ways to quickly identify clients. Having an
explicit signal from the client that it has an mTLS certificate on offer
reduces round-trips to find out, avoids unnecessarily probing clients that
have no certificate, etc. I think this would be an ideal use case for the
TLS Flags extension.

I have a pair of interoperable implementations (one based on boringssl and
one based on Go TLS) which I plan to open source before Prague. Obviously
these include implementations of the TLS Flags extension, which hopefully
will help drive that work forward too.

Regards,

Jonathan
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-10-23 Thread internet-drafts 
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-tls-ctls-09.txt
   Pages:   26
   Dates:   2023-10-23

Abstract:

   This document specifies a "compact" version of TLS 1.3 and DTLS 1.3.
   It saves bandwidth by trimming obsolete material, tighter encoding, a
   template-based specialization technique, and alternative
   cryptographic techniques. cTLS is not directly interoperable with TLS
   1.3 or DTLS 1.3 since the over-the-wire framing is different.  A
   single server can, however, offer cTLS alongside TLS or DTLS.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-ctls/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-ctls-09.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-ctls-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls