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

Andrei Popov <Andrei.Popov@microsoft.com> Mon, 10 August 2015 19:05 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 077951B3CBD for <tls@ietfa.amsl.com>; Mon, 10 Aug 2015 12:05:28 -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 lG2dzoN-soWO for <tls@ietfa.amsl.com>; Mon, 10 Aug 2015 12:05:26 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDBB1B3CC3 for <tls@ietf.org>; Mon, 10 Aug 2015 12:05:16 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 10 Aug 2015 19:04:57 +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 19:04:57 +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/RAIAB9sGQgAbZS4CAA6ghwIAACXUAgAAYGbA=
Date: Mon, 10 Aug 2015 19:04:57 +0000
Message-ID: <BLUPR03MB139693D20222F5459EFC907F8C700@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>
In-Reply-To: <7598CD3F-F111-4457-B225-4B7B12287437@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; BLUPR03MB1394; 5:X00fJBucSA88tmTBPQRLt/FUjnbfP8CArNp2qU949vSYbsDFqjYkSKv4wdndlxA0tpRM7LMowJiHvC6rrjTcjjr95k//JP78ue9j3+SzBDQ/QR2msZARl5kcKmdv87xJXWShIQvXzKQ2k/+JbljIUA==; 24:uqnD4sk5XRMxj8CSCQlKjjfZoCNG5/V52FkKZnN5zFDCKn0g7ibHL/or+mkLqXNRioDlTWMUxJXyvlM88rjBI+5USKmhi/OS3mBxSbEadt0=; 20:ZSAG5RNA+CsWpVCIzYzC8CT+7aLKG15cUnhW2pADB20wtLI5h35TFYnHEu2wodLUfQwkxC9FAjsa5YZl4rb9Ag==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394;
x-microsoft-antispam-prvs: <BLUPR03MB13942301BE409505E5813D738C700@BLUPR03MB1394.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:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394;
x-forefront-prvs: 06640999CA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(189002)(24454002)(199003)(377454003)(46102003)(2656002)(76576001)(2950100001)(33656002)(4001540100001)(81156007)(189998001)(19580405001)(5005710100001)(5001830100001)(64706001)(68736005)(122556002)(40100003)(62966003)(97736004)(5001860100001)(102836002)(110136002)(5002640100001)(77156002)(5001960100002)(10090500001)(77096005)(54356999)(5003600100002)(106116001)(106356001)(87936001)(19580395003)(99286002)(105586002)(86362001)(93886004)(50986999)(2900100001)(10400500002)(92566002)(74316001)(86612001)(76176999)(10290500002)(101416001)(8990500004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; 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)
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 19:04:57.3401 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/aFYYY7spJE4xOwiSm6hSUWCV7vI>
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 19:05:28 -0000

> 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. 

> 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.

Cheers,

Andrei

-----Original Message-----
From: Yoav Nir [mailto:ynir.ietf@gmail.com] 
Sent: Monday, August 10, 2015 10:28 AM
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 8:10 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> 
> Hi Ilari,
> 
>> What sort of usecase you have in mind for this?
> This is to support a fairly common website design where the landing page does not require client auth, but subsequent request to a protected resource triggers client authentication within an existing TLS connection.
> In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, there is no renegotiation, so we need an alternative solution if we want to support these existing sites over TLS1.3.

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.

Such sites were first broken by HTTP/2 which forbade renegotiation. Then they were broken again by TLS 1.3 that does not include renegotiation.

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. 

Assuming that HTTP/2 is the HTTP of the future (meaning that relegating these sites to HTTP/1 is a temporary thing), I don’t think that this new mechanism fixes the issue with renegotiation that caused httpbis to reject its usage. 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.

It would be useless IMO to create an alternate renegotiation in TLS only for it to not be used in HTTP/2.

Yoav