W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

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

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Sat, 26 Sep 2015 11:01:44 +0300
To: Willy Tarreau <w@1wt.eu>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20150926080144.GA352@LK-Perkele-VII>
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.

Received on Saturday, 26 September 2015 08:02:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:46 UTC