Re: Report on preliminary decision on TLS 1.3 and client auth

[Willy Tarreau <[e-mail]>]

On Fri, Sep 25, 2015 at 10:08:50AM -0700, Martin Thomson wrote:
> I think that your general observation about client certificates is
> overwhelmingly true.  On the web at least, I'm seeing a general trend
> away from using the TLS layer to authenticate clients.

On the *browser* web that's true, and the main reason is that if you
don't have your cert, you can't connect and you get a connect error
instead of a nice page delivered by the application proposing you to
regenerate your cert. Note: some sites manage to get it right, but
it's really complicated because the application needs to be aware of
what happens at the transport layer and needs to trust itself as much
as the transport layer, which is hardly a good thing to do by todays
development standards... And keep in mind that certs are a pain to
manage. Client certs are even worse because you have to support them
at the edge and manage them in the backend from the application. In
the end it provides no better security than the weakest point : the
application, which may sometimes be forced to generate rogue certs
due to regular bugs, but with a longer effect since these certs can
be abused even after the application bugs are fixed!

Between reverse-proxies and servers, or between servers, client certs
are much more common and perfectly fit the purpose : guarantee to each
side that they're talking with whom they believe they're talking. For
example, you don't forward an online payment request from an application
server on DC A to a payment server on DC B without client auth, or you're
definitely seeking for trouble. Just like you may only accept incoming
connections from your CDN.

> I'd like to find other solutions for the use cases that drive this,
> but the view was that we still needed something like this so that we
> don't strand those users on old protocols.  We don't have to *like* it
> though.
> 
> There was strong agreement that this feature would be accompanied by a
> prominent and severe admonishment against using it.  I definitely want
> to talk about what the alternatives look like, but perhaps we should
> start a separate thread on that subject.

We should always be careful not to make security look evil just because
it comes with privacy concerns. If I go to my bank and want to make a
wire transfer, I have to show my ID card. If at some point people feel
concerned that the person they're talking to suddenly knows their name
and that it's a privacy concern and that they'd rather not ask for the
ID card, I would feel much less safe because I would have a harder way
to prove I'm the one I'm claiming, and others could pretend to be me.

And if I had the choice between having to show my ID card to everyone
in the queue at the same time as the bank's employee, or murmuring a
secret word hoping noone else hears it, guess what ? I'd prefer to show
my ID card to everyone, because as long as I have it and I keep my face,
I'm sure to be the only one to be able to do this wire transfer, while
the secret word can leak and be reused (even by the employee after he
leaves the bank and ends up in the same queue as me).

There are many situations where identification and authentication are
required. And by doing so we have to disclose our identity. We just
have not to abuse this, and possibly remind those who request it that
those who are asked to provide it may feel uncomfortable and that
sometimes alternatives are just as good. But we should not make this
mechanism look evil because it does more good than bad.

Regards,
Willy