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

2023-11-08 Thread Viktor Dukhovni 
On Wed, Nov 08, 2023 at 03:54:05AM +, Andrei Popov wrote:

> A few concerns I have with this extension:
> 
>   1.  Privacy: clients broadcasting intent to identify themselves to
>   anyone who asks. I know, this is intended for crawler bots, but the
>   TLS stack does not know whether our caller is a bot, so we will have
>   to implement API support, which will be used by various
>   apps/services.

Unclear how that's worse than today, with clients offering the certs
when asked.

>   2.  Broadcasting intent to send a client cert before knowing the
>   CerrtificateRequest parameters is contrary to the design of TLS
>   client auth. What if the available client cert does not match the
>   future CertificateRequest?  3.  The stated goal is to use this
>   extension to selectively interrogate crawler bots. This extension
>   will only be useful for this purpose until general Web apps start
>   using it. Which they will do, once TLS stacks are updated to support
>   the new extension.

Unclear how that's worse than today, with servers asking for certs
regardless of whether the client promised to not break when asked.

Note that the extension is not a hard commitment to send a client cert,
rather a promise to gracefully tolerate a request.  So the client still
decides after receiving the request, just like it does now.

All that changes, is that servers get the opportunity to be more
selective about when to ask.

> Doesn't the proposed extension facilitate surveillance by letting an
> unauthenticated TLS sever know that the client is willing to divulge
> its identity, and that querying client identity won't disrupt the flow
> or cause any notification to the user?

Not more than today, for servers that are willing to solicit the cert.
Note that for an MiTM scenario, injecting the request mutates the
session transcript, so authenticated impersonation is not available.

Again nothing changes, other than servers being able to be a bit more
selective about whom they'll ask.  Everything else is the same,
including various scenarios where "bad guys" can already ask the client.

-- 
Viktor.

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

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

2023-11-07 Thread Andrei Popov 
A few concerns I have with this extension:

  1.  Privacy: clients broadcasting intent to identify themselves to anyone who 
asks. I know, this is intended for crawler bots, but the TLS stack does not 
know whether our caller is a bot, so we will have to implement API support, 
which will be used by various apps/services.
  2.  Broadcasting intent to send a client cert before knowing the 
CerrtificateRequest parameters is contrary to the design of TLS client auth. 
What if the available client cert does not match the future CertificateRequest?
  3.  The stated goal is to use this extension to selectively interrogate 
crawler bots. This extension will only be useful for this purpose until general 
Web apps start using it. Which they will do, once TLS stacks are updated to 
support the new extension.

Doesn't the proposed extension facilitate surveillance by letting an 
unauthenticated TLS sever know that the client is willing to divulge its 
identity, and that querying client identity won't disrupt the flow or cause any 
notification to the user?


Cheers,


Andrei


From: TLS  on behalf of Ilari Liusvaara 

Sent: Tuesday, November 7, 2023 3:36 PM
To:  
Subject: [EXTERNAL] 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
> interpretation beyond "always send" or "never send".

Explicit configuration to send this for some names/domains.

Needed for some "enterprise" use cases (can also pop up in much smaller
corporate contexts).




-Ilari

___
TLS mailing list
TLS@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C01%7CAndrei.Popov%40microsoft.com%7Cb542a7f746b74d5d539508dbdf9efbfe%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638349646193968016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=9sTyFEtT1T3jmXmxjjFGAj39PbEms6IQfC1l1fX0Gug%3D=0
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-10-25 Thread Jonathan Hoyland 
Hi all,

So as David mentioned, this doesn't really offer anything for human
clients, and is aimed at reliably distinguishing between bots. To be honest
it might be better that browsers not implement it, because that massively
increases the number of potential users, and thus the noise we get from the
hint.

I wasn't aware that some devices ask for a cert and then choke if you send
one, although that sounds like a misconfigured server to me.

There is an argument for echoing the flag back to the client, which is to
distinguish the case where the server wants a client cert for other
reasons, and the case where it supports and honours this flag.

I decided not to include it though because I couldn't think of a plausible
situation where knowing that information would be useful.

I guess the "misconfigured servers exist" use case is plausible, so I'm
open to including it, but it seems to me that all it will do is produce a
new generation of differently misconfigured servers that set this flag and
choke when you send them a cert.
Regards,

Jonathan


P.S. mTLS is simply a shorthand for establishing a TLS session with
bilateral authentication. I could write that out in full every time, but it
doesn't add anything.

On Wed, 25 Oct 2023, 11:48 Peter Gutmann,  wrote:

> Viktor Dukhovni  writes:
>
> >I think what you're really saying, is that it may be time replace the
> extant
> >client certificate request message with a completely new one, because the
> old
> >one is ossified.
>
> No, just have the server echo back the cert-auth flag from the client to
> indicate that it really wants to do this.
>
> Either that or mention in the RFC that some servers will send a cert
> request
> no matter what, so getting a cert request in response to an mTLS flag [*]
> doesn't necessarily mean that the server is expecting cert auth.  Adding
> the
> note at least makes it Someone Else's Problem.
>
> Peter.
>
> [*] Why is it called mTLS?  It's just TLS, mTLS doesn't add anything new
> that
> hasn't been in there for decades.
>
> ___
> 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-25 Thread Peter Gutmann 
Viktor Dukhovni  writes:

>I think what you're really saying, is that it may be time replace the extant
>client certificate request message with a completely new one, because the old
>one is ossified.

No, just have the server echo back the cert-auth flag from the client to
indicate that it really wants to do this.

Either that or mention in the RFC that some servers will send a cert request
no matter what, so getting a cert request in response to an mTLS flag [*]
doesn't necessarily mean that the server is expecting cert auth.  Adding the
note at least makes it Someone Else's Problem.

Peter.

[*] Why is it called mTLS?  It's just TLS, mTLS doesn't add anything new that
hasn't been in there for decades.

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

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

2023-10-24 Thread Viktor Dukhovni 
On Wed, Oct 25, 2023 at 02:34:08AM +, Peter Gutmann wrote:

> Andrei Popov  writes:
> 
> >An "I really mean it" flag. We can add these for every TLS message, not just
> >authentication-related ones. Just to make sure the peer truly is serious
> >about the TLS handshake.
> 
> It really depends on how servers react when they see client-cert-auth when
> they're not expecting it.  Some time ago I tested one of the always-requests-
> client-auth servers to see what happened when it actually did get client-cert-
> auth and the result was a Handshake Failure alert.  For J.Random messages it
> won't matter, but if the server is requesting client auth without knowing it's
> doing it then some "I really mean it" indication back to the client might be
> useful.

I think what you're really saying, is that it may be time replace the
extant client certificate request message with a completely new one,
because the old one is ossified.

That could mean "I really mean it", until some server code turns it on
by default again...  We can't win that battle.

I work on Postfix, I always recomment that users don't enable client
cert requests for no good reason.  And yet, we provide the feature to
make it possible, and some users then truly believe that it is necessary
to ask for certs they can't/won't use.

Postfix fortunately does not misbehave when useless certs arrive, but
the basic seed of doom is in the user behaviour.

https://marc.info/?l=postfix-users=169565176912422=2

> If you also have TLS client certs configured (typically without just
> cause) to be sent to servers that happen to request them (also typically
> without just cause), then a failure to load the client certs breaks TLS
> support in tlsproxy(8), which makes all attempts at "STARTTLS" fail.

Yes, list.sys4.de also uses TLS client certs and I'm not really sure
I like you writing "typically without just cause". I'd rather have
it the other way around and be irritated if clients do not identify
themselves in TLS sessions as well.

For some quixotic reason, this is particularly common in Germany.

-- 
Viktor.

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

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

2023-10-24 Thread Peter Gutmann 
Andrei Popov  writes:

>An "I really mean it" flag. We can add these for every TLS message, not just
>authentication-related ones. Just to make sure the peer truly is serious
>about the TLS handshake.

It really depends on how servers react when they see client-cert-auth when
they're not expecting it.  Some time ago I tested one of the always-requests-
client-auth servers to see what happened when it actually did get client-cert-
auth and the result was a Handshake Failure alert.  For J.Random messages it
won't matter, but if the server is requesting client auth without knowing it's
doing it then some "I really mean it" indication back to the client might be
useful.

Peter.

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

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

2023-10-24 Thread Viktor Dukhovni 
On Tue, Oct 24, 2023 at 04:13:48PM +, Andrei Popov wrote:

> > So it may be necessary to have the server respond with its own flag
> > to indicate that it really does want client cert auth and isn't just
> > asking for a client cert on autopilot.
>
> An "I really mean it" flag. We can add these for every TLS message,
> not just authentication-related ones. Just to make sure the peer truly
> is serious about the TLS handshake.

I hope Peter wasn't entirely serious... If the client offers and the
server asks, there's nothing to be gained from yet another extension,
the server operators who unwittingly enabled (or left defaults
unchanged) server requests for client auth, will similarly unwitingly
enable the new flag.

The proposed "I'm a bot with a cert, please ask me for my bot driver's
license", flag could I think be helpful to server operator who want
to request certs from just that population of bots.

This isn't a burning issue however, just a nice to have.  We've somehow
gotten by without it so far, and indeed if all clients that had no
a priori reason to volunteer a cert, simply ignored all requests, the
flag would not be needed.

-- 
Viktor.

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

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

2023-10-24 Thread David Benjamin 
On Tue, Oct 24, 2023, 13:07 Viktor Dukhovni  wrote:

> On Tue, Oct 24, 2023 at 12:54:08PM -0400, David Benjamin wrote:
>
> > Is the concern here errors or prompting? From the original email, it
> > sounded like the issue was that requesting client certificates showed
> > undesirable UI to human-backed clients.
>
> My concern is errors, browser UX concerts are not my bailiwick.  I
> typically look at TLS from the perspective of SMTP, where all the
> communication is bot-to-bot (MTA to MTA).
>
> But, you're right that prompting could also be an issue, since in this
> case the use-case was MUA to MSA, so it would apply to Thunderbird,
> Outlook, ... where there's a user behind the keyboard.
>
> I don't recall seeing prompting as an issue reported by MUA users, since
> the MUA authentication method is typically pre-configured as part of the
> "server settings".  MUAs have the luxury of a static set of servers they
> talk to, where pre-configuration is the norm.
>

Ah yeah, I should have been clearer that I was specifically talking about
HTTPS human clients. Hopefully MUAs didn't make quite the same set of
historical deployment mistakes that HTTPS UAs did around client certs! :-)



-- 
> 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-24 Thread Viktor Dukhovni 
On Tue, Oct 24, 2023 at 12:54:08PM -0400, David Benjamin wrote:

> Is the concern here errors or prompting? From the original email, it
> sounded like the issue was that requesting client certificates showed
> undesirable UI to human-backed clients.

My concern is errors, browser UX concerts are not my bailiwick.  I
typically look at TLS from the perspective of SMTP, where all the
communication is bot-to-bot (MTA to MTA).

But, you're right that prompting could also be an issue, since in this
case the use-case was MUA to MSA, so it would apply to Thunderbird,
Outlook, ... where there's a user behind the keyboard.

I don't recall seeing prompting as an issue reported by MUA users, since
the MUA authentication method is typically pre-configured as part of the
"server settings".  MUAs have the luxury of a static set of servers they
talk to, where pre-configuration is the norm.

-- 
Viktor.

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

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

2023-10-24 Thread David Benjamin 
Is the concern here errors or prompting? From the original email, it
sounded like the issue was that requesting client certificates showed
undesirable UI to human-backed clients.

That one is a bit harder to avoid since no one is acting incorrectly per
se. Clients for humans need to ask the human for consent before revealing
identity information. They also need to be mindful of things like
background contexts, in which prompting isn't possible. Also some platforms
are such that querying for certs and prompting is one operation, which
limits the solution space.

All this together means that optional client certificates, for HTTPS
services that are accessed by humans, basically does not work, even though
everything works fine at the protocol level.

Really the problem is that authentication for robots and authentication for
humans have different UX requirements. But we're kind of stuck because this
particular mechanism, years ago, got used for human authentication despite
not actually being terribly suitable for it.

On Tue, Oct 24, 2023, 12:37 Viktor Dukhovni  wrote:

> On Tue, Oct 24, 2023 at 04:11:53PM +, Andrei Popov wrote:
>
> > > 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.
> >
> > This is exactly my argument: when a client receives a cert request the
> > client cannot satisfy, the RFC says send an empty Certificate and
> > continue with the handshake...
>
> Sadly, that's not what actually reliably happens in practice, or at
> least that was the case when I last looked.
>
> Perhaps all the guilty TLS stacks were fixed in the meantime?  I am not
> well placed to determine how much "friction" remains.
>
> --
> 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-24 Thread Viktor Dukhovni 
On Tue, Oct 24, 2023 at 04:11:53PM +, Andrei Popov wrote:

> > 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.
>
> This is exactly my argument: when a client receives a cert request the
> client cannot satisfy, the RFC says send an empty Certificate and
> continue with the handshake...

Sadly, that's not what actually reliably happens in practice, or at
least that was the case when I last looked.

Perhaps all the guilty TLS stacks were fixed in the meantime?  I am not
well placed to determine how much "friction" remains.

-- 
Viktor.

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

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

2023-10-24 Thread Andrei Popov 
> So it may be necessary to have the server respond with its own flag to 
> indicate that it really does want client cert auth and isn't just asking for 
> a client cert on autopilot.
An "I really mean it" flag. We can add these for every TLS message, not just 
authentication-related ones. Just to make sure the peer truly is serious about 
the TLS handshake.


-Original Message-
From: TLS  On Behalf Of Peter Gutmann
Sent: Tuesday, October 24, 2023 12:55 AM
To: tls@ietf.org
Subject: Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

Viktor Dukhovni  writes:

>I don't see in your comment anything to suggest that the flag is a no-go.

Oh, it's definitely not a no-go, just pointing out that you shouldn't read too 
much into seeing a cert request from a server.  In other words if the client 
says "I have a cert" and the server responds "please authenticate using the 
cert", that doesn't mean that the server will actually expect client cert auth 
at that point.

So it may be necessary to have the server respond with its own flag to indicate 
that it really does want client cert auth and isn't just asking for a client 
cert on autopilot.

Peter.

___
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-24 Thread Andrei Popov 
> 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.
This is exactly my argument: when a client receives a cert request the client 
cannot satisfy, the RFC says send an empty Certificate and continue with the 
handshake...

-Original Message-
From: Peter Gutmann  
Sent: Monday, October 23, 2023 7:41 PM
To: Andrei Popov ; tls@ietf.org
Subject: 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 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-24 Thread Peter Gutmann 
Viktor Dukhovni  writes:

>I don't see in your comment anything to suggest that the flag is a no-go.

Oh, it's definitely not a no-go, just pointing out that you shouldn't read too
much into seeing a cert request from a server.  In other words if the client
says "I have a cert" and the server responds "please authenticate using the
cert", that doesn't mean that the server will actually expect client cert auth
at that point.

So it may be necessary to have the server respond with its own flag to
indicate that it really does want client cert auth and isn't just asking for a
client cert on autopilot.

Peter.

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

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

2023-10-24 Thread Viktor Dukhovni 
On Tue, Oct 24, 2023 at 02:40:35AM +, Peter Gutmann wrote:

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

The breakage being, I assume, the pointless asking.  I assume that you
wouldn't object to servers *conditionally* asking if:

- The client explicitly signalled willingness
- The server actually has a use for some client certs, but does
  not always require them.

I don't see in your comment anything to suggest that the flag is a
no-go. 

To David's point, I don't expect browsers to ever set it, at least not
without some advanced user configuration that almost nobody would set,
though you never know what "enterprise" customers will ask for...

-- 
Viktor.

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

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