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

[Ilari Liusvaara <[e-mail]>]

On Sat, Sep 26, 2015 at 08:37:38AM +0200, Willy Tarreau wrote:
> 
> 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.

IMO, there are two kinds of certs in web environment (service to
service and non-web client-to-server are different ballgames):

1) "global": Shared among all authorized origins.
- Breaks SOP, making these highly privileged.
- Not automatable given the privilege involved.
- Private parts on smartcards or softokens.
- Usually identifies user
- Serious privacy concerns (but sometimes needed).

2) "local": Single origin
- Respects SOP.
- Can be almost entierely automatic (relatively unprivileged).
- Webcrypto, FIDO, etc...
- Usually pseudonymous
- Privacy concerns on level of things like LocalStorage.


There is friction with HTTP/2 connection coalescing here:
- "Global": If connection is for origins A and B, even if cert is
  authorized for A, it might not be authorized for B.
- "Local": If connection is for origins A and B, there can't be
  any single cert for the connection.

Also, some requests can't be sent with client cert at all (cross-origin
non-credentials fetch() for instance), even if target origin has
associated client cert.


-Ilari