Re: [TLS] Commentary on the client authentication presentation slides

Andrei Popov <> Tue, 04 August 2015 00:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 316A71B3251 for <>; Mon, 3 Aug 2015 17:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aUIlicUJOjwm for <>; Mon, 3 Aug 2015 17:38:09 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::1:764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A575A1B325D for <>; Mon, 3 Aug 2015 17:38:08 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 4 Aug 2015 00:37:47 +0000
Received: from ([]) by ([]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 00:37:47 +0000
From: Andrei Popov <>
To: Ilari Liusvaara <>, David Benjamin <>
Thread-Topic: [TLS] Commentary on the client authentication presentation slides
Date: Tue, 04 Aug 2015 00:37:47 +0000
Message-ID: <>
References: <20150720141036.GA32204@LK-Perkele-VII> <> <> <> <20150801084849.GA7162@LK-Perkele-VII> <> <20150802182908.GA29836@LK-Perkele-VII>
In-Reply-To: <20150802182908.GA29836@LK-Perkele-VII>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:2::1d2]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:Hmm+vOOwq0xdYgbphlKRl9En98ktj8nDb//TSAVho23XbrJ8avU04L//TjIDFpc1J1rqON9ScAelN0CCpKHlI6y/Oyc6q8CbD/pftNPaA9wEehOjacTV0GOxofYy+2gRRigvbIpTVKwmdMUHPLSVEQ==; 24:hxTiK+0t3r5M+ZkMCm2lgZEM7m+yJlfrDHB93Yhb02zqiEAFMzAuQoeAz/ehdwm2mQs/OMSgulxJP7LhJKss7a/zATY613zAL7OvrxKp1+g=; 20:jTXuxw2oNp6ffBE3SidZ+piVqjeGuFPkzojD4bTyevv9Py6JncTL65lEpwsED8/96oY5PLMf+pJcarViIF9Rog==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396;
x-forefront-prvs: 0658BAF71F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(189002)(199003)(19580395003)(2656002)(76576001)(87936001)(10090500001)(33656002)(93886004)(101416001)(99286002)(46102003)(561944003)(54356999)(50986999)(76176999)(86612001)(74316001)(86362001)(106356001)(105586002)(106116001)(5002640100001)(92566002)(2950100001)(2900100001)(122556002)(62966003)(81156007)(19580405001)(77156002)(40100003)(5001960100002)(64706001)(97736004)(189998001)(77096005)(68736005)(4001540100001)(102836002)(5001830100001)(5001860100001)(5003600100002)(5001770100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2015 00:37:47.3160 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Commentary on the client authentication presentation slides
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Aug 2015 00:38:11 -0000

> Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS.
> There one likely "preconfigures" client certificates if needed.
The proposed client authentication mechanism specifically addresses the case where the client does not have one "preconfigured" cert.

> - TLS-level client certificate auth on client request on connect (this
>  currently can't be cleanly done, sometimes one even sees that "renego
>  immediately to provoke CR" hack).
With the proposed change, there will be no need to renegotiate in order to authenticate the client.

 > - Application-level client auth (via CB capability of TLS).
The proposed mechanism does not preclude this option.



-----Original Message-----
From: Ilari Liusvaara [] 
Sent: Sunday, August 2, 2015 11:29 AM
To: David Benjamin <>
Cc: Andrei Popov <>;
Subject: Re: [TLS] Commentary on the client authentication presentation slides

On Sun, Aug 02, 2015 at 03:38:00PM +0000, David Benjamin wrote:
> On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara 
> <>
> wrote:
> >
> > What I think would be very useful: A way for client to signal it has 
> > a client certificate it expects to use, regardless of if valid 
> > configuration is known. The vast majority of times client 
> > certificate is used, the client knows about that before initiating a connection.
> Unless I misunderstand you, this isn't true for a browser. Browsers 
> only look for client certificates based on a CertificateRequest 
> message. Some platforms, like Android, don't even let you list the 
> user's certificate store. Instead there's an API to show a trusted certificate picker prompt.

Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS.
There one likely "preconfigures" client certificates if needed.

> Or, given the paragraph below, are you suggesting that we'd start a 
> second connection on receiving CertificateRequest and only advertise it then?
> Yeah, that's actually how Chrome implements client auth anyway. We 
> always start a second connection with a client certificate configured, 
> even if the server sent CertificateRequest on a renego. It makes a few things simpler.

Doesn't that count as "knowing about client certificate before connecting"
(even if the knowledge has been received split-second before TLS handshake starts)?

Also, signaling can be at application layer, as talked about below.

> > IMO, the proper way to handle "this resource requires client certificate"
> > is for server to signal that in application protocol and then client 
> > to establish a new connection with client certificate (or if 
> > application protocol supports it, do the authentication at 
> > application layer without ever involving TLS, except for channel binding).
> Certainly. Chrome doesn't implement TLS_RENEG_PERMITTED for HTTP/2, 
> and I don't want to allow this mechanism for it either. I consider 
> renego-based per-resource client auth in HTTP/1.1 to be a legacy 
> mistake we're currently stuck with. (It's the only reason we ever have 
> to renego. In BoringSSL, we've settled on stripping renego down to the 
> bare minimum needed to support this. Simplifies a lot of stuff.)

Yeah, I consider it (renego auth in HTTP/1.1) a poor idea as well, and I consider it would be actively dangerous in browser HTTP/2 (due to the multipoint nature of the environment and multiplexed nature of HTTP/2)...
Good thing it is banned.

> I'm guessing Microsoft has different constraints/goals, given this 
> proposal and TLS_RENEG_PERMITTED, so if we must have it in the 
> transport, I'd rather it be some opt-in corner that I don't have to 
> deal with. (Applications can return HTTP_1_1_REQUIRED in HTTP/2 if 
> they really must do per-resource client auth.) But I do agree this is 
> a problematic mechanism and don't think it belongs in TLS. Let the 
> application layer do it with a channel binding. No need for new 
> connections, and no messy questions about scope and multi-request protocols.

Summary of what auth modes I think are needed:

- TLS-level client certificate auth on client request on connect (this
  currently can't be cleanly done, sometimes one even sees that "renego
  immediately to provoke CR" hack).
- Application-level client auth (via CB capability of TLS).