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

Andrei Popov <> Tue, 11 August 2015 18:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0D9E01ACE31 for <>; Tue, 11 Aug 2015 11:11:18 -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 8AzUH7UgC0iB for <>; Tue, 11 Aug 2015 11:11:16 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 888101ACE3E for <>; Tue, 11 Aug 2015 11:11:14 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 11 Aug 2015 18:10:53 +0000
Received: from ([]) by ([]) with mapi id 15.01.0225.018; Tue, 11 Aug 2015 18:10:53 +0000
From: Andrei Popov <>
To: Martin Thomson <>, Dave Garrett <>
Thread-Topic: [TLS] Commentary on the client authentication presentation slides
Thread-Index: AQHQ1FRNSiLWIyLp306JLFOxlCsn654HDhfw
Date: Tue, 11 Aug 2015 18:10:53 +0000
Message-ID: <>
References: <20150720141036.GA32204@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> <> <> <>
In-Reply-To: <>
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:LXE7F30EgLyOV8X5P1tG1zPKwUEp2Ua6Vgmt3LkvHtW1vfHWkBX7GeYRO/a1gRORVWlkfwnGit/31NWIGMq/8vgYQXQrWMNGF2nRbzhdWY8+YVGCoAkHgdBPcV2fhlMKEoHXGCDAZwPRMNlHGXEIyg==; 24:EfJhHcF3rThmg5WgRfkMUt0DMUdtMrht2Qtq5BgP81/Eqsy0Yh38WAB8BcxX1Erg/A9k6r9a+3FSKpalvM6uMr9I0x7ncG+/1dlxvEhUEDM=; 20:33blxaCAC+U7tEMEtxYXmCUCguqjf8nNR/ILB97XGepGormHSG+HEx/vuv2cDopy5Z9K+cF9WDkh39NDXQcnxQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
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: 066517B35B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(13464003)(377454003)(24454002)(46102003)(92566002)(5001770100001)(5001960100002)(5002640100001)(97736004)(4001540100001)(189998001)(5001830100001)(5001860100001)(81156007)(64706001)(19580405001)(50986999)(76176999)(76576001)(54356999)(33656002)(77096005)(2900100001)(15975445007)(5003600100002)(122556002)(68736005)(102836002)(86362001)(77156002)(62966003)(2950100001)(10090500001)(40100003)(5005710100001)(87936001)(99286002)(8990500004)(19580395003)(2656002)(10290500002)(10400500002)(105586002)(106356001)(93886004)(86612001)(101416001)(74316001)(106116001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2015 18:10:53.5307 (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, 11 Aug 2015 18:11:18 -0000

Indeed, I think cant-care has a number of disadvantages:
1. Introduces round-trips to establish a new TCP connection;
2. Requires a new TLS handshake, with associated costs.
3. Uses two CertificateRequests: one at the HTTP layer, and another at the TLS layer. Somehow we would need to figure out how to make them match, or have the client ignore TLS-level cert filtering parameters?
4. Pushes the problem to the application layer: any application protocol that uses mid-stream client auth will require an update. (I know, some will say we are only aware of HTTPS scenarios right now.)

At the cost of all of the above, cant-care allows the client to determine exactly which HTTP request has resulted in the client auth request. I think there may be a compromise where we can identify this HTTP request without requiring a reconnect. E.g. what about CertificateRequest at the HTTP layer + TLS client sending Certificate/CertificateVerify after the handshake in the middle of the existing TLS connection?



-----Original Message-----
From: TLS [] On Behalf Of Martin Thomson
Sent: Tuesday, August 11, 2015 9:39 AM
To: Dave Garrett <>
Subject: Re: [TLS] Commentary on the client authentication presentation slides

Before people get too far down that road, here:

Andrei has made it clear that these do not work for his use case (I'm not yet convinced that they are inadequate, but I am convinced of the fact that Andrei thinks that they are inadequate ;).


This is well-trodden ground.

On 10 August 2015 at 23:05, Dave Garrett <> wrote:
> On Monday, August 10, 2015 01:10:38 pm Andrei Popov wrote:
>> > 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.
> This is just an idea, but what about just allowing a renegotiation-like mechanism via 0-RTT with PSK resumption to be triggered on a TLS alert or HTTP response code? The rough idea would be like this:
> 1) client connects to server and fetches public resources
> 2) client requests restricted resource; server sends auth required 
> response (TLS alert or HTTP code)
> 3) client creates a replacement connection using PSK-based resumption and early data in the first flight for the request along with the client cert.
> There's a 1 roundtrip cost in there for a new TCP connection, which could possibly be optimized away by using TCP fast open.
> This general concept is relatively simple in comparison to doing something mid-connection. Instead of attempting to renegotiate on an existing connection, just make creation of resumed connections cheap enough to start over with client auth in the handshake from the start.
> It's a very rough idea, but I'm wondering if it sounds like something worth discussing.
> Dave
> _______________________________________________
> TLS mailing list

TLS mailing list