On Wed, Nov 08, 2023 at 03:54:05AM +0000, 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
