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
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
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
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
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
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
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
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
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
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
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
-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
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 wo
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
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
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
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
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
>
>> 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.
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
20 matches
Mail list logo
