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

Ilari Liusvaara <> Sat, 26 September 2015 08:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BF7C01B2B47 for <>; Sat, 26 Sep 2015 01:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CD6v1Yhg3dlI for <>; Sat, 26 Sep 2015 01:06:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C73F21B2B45 for <>; Sat, 26 Sep 2015 01:06:12 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZfkR0-00033J-C7 for; Sat, 26 Sep 2015 08:02:18 +0000
Resent-Date: Sat, 26 Sep 2015 08:02:18 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZfkQt-00031n-R6 for; Sat, 26 Sep 2015 08:02:11 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1ZfkQq-0002RT-Jk for; Sat, 26 Sep 2015 08:02:11 +0000
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id EB8B71A2606; Sat, 26 Sep 2015 11:01:44 +0300 (EEST)
Date: Sat, 26 Sep 2015 11:01:44 +0300
From: Ilari Liusvaara <>
To: Willy Tarreau <>
Cc: HTTP Working Group <>
Message-ID: <20150926080144.GA352@LK-Perkele-VII>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: Ilari Liusvaara <>
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: AWL=-0.851, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ZfkQq-0002RT-Jk 5a8e2b0a55df5579218c87eee01ef451
Subject: Re: Report on preliminary decision on TLS 1.3 and client auth
Archived-At: <>
X-Mailing-List: <> archive/latest/30281
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.