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

Andrei Popov <Andrei.Popov@microsoft.com> Mon, 10 August 2015 20:18 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 CE63D1B3DA7 for <tls@ietfa.amsl.com>; Mon, 10 Aug 2015 13:18:27 -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 QmbgkmBOmMrn for <tls@ietfa.amsl.com>; Mon, 10 Aug 2015 13:18:25 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:714]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851F61B3DA0 for <tls@ietf.org>; Mon, 10 Aug 2015 13:18:25 -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; Mon, 10 Aug 2015 20:18:05 +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; Mon, 10 Aug 2015 20:18:05 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Thread-Topic: [TLS] Commentary on the client authentication presentation slides
Thread-Index: AQHQwvXiSxNxWYXIoUOvWC1ZP+t1vJ3qDNvQgAd2zoCAAABcAIAFY9OAgAIEqACAAC/RAIAB9sGQgAbZS4CAA6ghwIAACXUAgAAYGbCAABB0AIAAAkiw
Date: Mon, 10 Aug 2015 20:18:05 +0000
Message-ID: <BLUPR03MB1396D8AA255037AF20C0D5338C700@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> <BLUPR03MB139631EC62ABC0732E0C70CA8C760@BLUPR03MB1396.namprd03.prod.outlook.com> <20150808090351.GA14947@LK-Perkele-VII> <BLUPR03MB1396C25B04D58DB47C9676AE8C700@BLUPR03MB1396.namprd03.prod.outlook.com> <7598CD3F-F111-4457-B225-4B7B12287437@gmail.com> <BLUPR03MB139693D20222F5459EFC907F8C700@BLUPR03MB1396.namprd03.prod.outlook.com> <17986EB3-08CC-4AB5-92FB-D101FA23A6E1@gmail.com>
In-Reply-To: <17986EB3-08CC-4AB5-92FB-D101FA23A6E1@gmail.com>
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:4::1d2]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:cmvKJfPjMWdvjyhdZjulUqy7Zggsy7X5wtaS+FPZTired3mT6+z5nB0iX4w3E/ds4Jq+gkTB4hXhWwHLbOf5n8n4+QAazj9/enrhMhyBt0M43IKNByud0R55rQYwNKwnfk8k7aHSTkmSA4EJU/BtHg==; 24:xhClxONz74kXDp+943rsvmVbENSP7DD54sEVkSMKE2FrGSMC9aJDjD17AeOMw3PQU/tTUXaBtLzhA8n8uTMn/Aabr++cWApxLpRDmM5buEA=; 20:sO7L5qKTBtoeD+uE7YF0EJW8kxV+1M8fX2ChSGmIScCY97Zk5Cq4PtjS3mtBfEGR4VduMSB3kcKnl6gykIw4Xg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396;
x-microsoft-antispam-prvs: <BLUPR03MB13960C24BA508A587EF369048C700@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: 06640999CA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(199003)(189002)(50986999)(110136002)(40100003)(2950100001)(93886004)(10090500001)(86362001)(81156007)(76576001)(101416001)(102836002)(122556002)(19580405001)(77096005)(68736005)(77156002)(8990500004)(10400500002)(5005710100001)(62966003)(2900100001)(92566002)(46102003)(5003600100002)(5001860100001)(10290500002)(74316001)(4001540100001)(2656002)(76176999)(97736004)(99286002)(54356999)(33656002)(189998001)(19580395003)(64706001)(106116001)(5001960100002)(5001830100001)(105586002)(87936001)(106356001)(5002640100001)(86612001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2015 20:18:05.3561 (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/oqR2qgVbreP1QTGniBmOb3dMBZU>
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: Mon, 10 Aug 2015 20:18:28 -0000

> One solution would be to move the authentication for this use case (and perhaps for HTTPS in general) from the transport layer to either HTTP as an authentication method or to the application (through some standardized exchange of JSON objects).
Doesn't this require an update of the site? If so, it defeats our goal of supporting existing sites over new protocols.

> Another option is to allow renegotiation and your mechanism in HTTP/2 with some change of behavior that eliminates the race condition.
I'm not sure what purpose #3 (HTTP control frame with the highest number of resource) serves. Couldn't we just say the client must not send new requests after receiving CertificateRequest and until sending CertificateVerify?

> This is a somewhat contrived example, but consider an object in the web page that says “Hello, guest” when no credential is available, and “Hello, Andrei” when a credential is available.  If the page has optional authentication and you have presented the certificate, then depending on timing you might still see “Hello, guest” on the page.
This just means that a request was answered at the time there was no client credential. This page probably needs to be a resource that requires client auth.

-----Original Message-----
From: Yoav Nir [mailto:ynir.ietf@gmail.com] 
Sent: Monday, August 10, 2015 12:53 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>fi>; tls@ietf.org
Subject: Re: [TLS] Commentary on the client authentication presentation slides


> On Aug 10, 2015, at 10:04 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> 
>> Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2.
> Correct, anything less than this will create deployment problems.
> 
>> I’d like to point out that I am very interested in this use case, but I’m not sure that this is the solution.
> I'm open to alternatives that fix the broken use case. 

One solution would be to move the authentication for this use case (and perhaps for HTTPS in general) from the transport layer to either HTTP as an authentication method or to the application (through some standardized exchange of JSON objects).

Another option is to allow renegotiation and your mechanism in HTTP/2 with some change of behavior that eliminates the race condition. For example:
 1. The server receives a request for a resource that requires a client certificate  2. The server sends a new HTTP message (or code) that says that client certificate authentication is required.
 3. The client sends a new HTTP control frame with the highest number of resource that it has requested.
 4. The server finishes serving all resources that don’t need authentication with a number below what the client sent  5. The client does not initiate any new requests.
 6. When the server is done, it initiates renegotiation or the new mechanism  7. After renegotiation, the client can resume sending requests, all of which are authenticated.

The details may be different, but something like this can bring determinism to the process.

>> We still get a race condition where several requests might be answered before, after or during authentication depending on the timing of the TLS handshake message vs the HTTP messages.
> The idea is that before answering a request that requires client auth, the server checks if a client cred is available. If there is no suitable client cred available, the request is blocked until the client authenticates. This does not necessarily have to block other requests that do not require client auth.

This is a somewhat contrived example, but consider an object in the web page that says “Hello, guest” when no credential is available, and “Hello, Andrei” when a credential is available.  If the page has optional authentication and you have presented the certificate, then depending on timing you might still see “Hello, guest” on the page.

Yoav