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

Andrei Popov <Andrei.Popov@microsoft.com> Tue, 04 August 2015 00:38 UTC

Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316A71B3251 for <tls@ietfa.amsl.com>; Mon, 3 Aug 2015 17:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUIlicUJOjwm for <tls@ietfa.amsl.com>; Mon, 3 Aug 2015 17:38:09 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A575A1B325D for <tls@ietf.org>; Mon, 3 Aug 2015 17:38:08 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 00:37:47 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 00:37:47 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, David Benjamin <davidben@chromium.org>
Thread-Topic: [TLS] Commentary on the client authentication presentation slides
Thread-Index: AQHQwvXiSxNxWYXIoUOvWC1ZP+t1vJ3qDNvQgAd2zoCAAABcAIAFY9OAgAIEqACAAC/RAIAB9sGQ
Date: Tue, 4 Aug 2015 00:37:47 +0000
Message-ID: <BLUPR03MB139631EC62ABC0732E0C70CA8C760@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <20150720141036.GA32204@LK-Perkele-VII> <BLUPR03MB1396E33D0B7ADBED918C54D08C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAF8qwaAAXv3Ts8JB25e5GB4Xrh8DU2Xg3UCXuDUObgGHubUFUw@mail.gmail.com> <CAF8qwaCz=ZtdANYas+vSatJGzai6AeyiLtw7_H_qP9iXf7dV8g@mail.gmail.com> <20150801084849.GA7162@LK-Perkele-VII> <CAF8qwaBADYYuKNkUnanJOwv3+ZurDHK3QTmQMsyqJ-a4yiSkKw@mail.gmail.com> <20150802182908.GA29836@LK-Perkele-VII>
In-Reply-To: <20150802182908.GA29836@LK-Perkele-VII>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
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: <BLUPR03MB1396DD5BA87B12842905C8EC8C760@BLUPR03MB1396.namprd03.prod.outlook.com>
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; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
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: <http://mailarchive.ietf.org/arch/msg/tls/K3swC8wV2rEU2QPrR1a28Ejy2_0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Commentary on the client authentication presentation slides
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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.

Cheers,

Andrei

-----Original Message-----
From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] 
Sent: Sunday, August 2, 2015 11:29 AM
To: David Benjamin <davidben@chromium.org>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>om>; tls@ietf.org
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 
> <ilari.liusvaara@elisanet.fi>
> 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).



-Ilari