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

Andrei Popov <> Mon, 10 August 2015 17:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 469451B3A19 for <>; Mon, 10 Aug 2015 10:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0G2N6e3IRaO2 for <>; Mon, 10 Aug 2015 10:10:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B92E1B3A17 for <>; Mon, 10 Aug 2015 10:10:40 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 10 Aug 2015 17:10:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aGHcTvctw3zAQFkHXeP/KQPEZTobK7wSiIYFqVD2O3k=; b=RnJ/I3YKtVbWgBaH/Sr5y3PLtPEcyYWymGqKJoT0s1uab+lzYfmhTJQ2FgMwl0G68Ii21UZW1lFKR/VqPPgirg4ZoaYQuoYAQ9/tUX8JbDk7q1qmWIyAHJ6mLWTA4Zmu2ehboK909o+tj9lTDpkLQlIXtMAMmKlTjS+fSzYTP80=
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 10 Aug 2015 17:10:38 +0000
Received: from ([]) by ([]) with mapi id 15.01.0225.018; Mon, 10 Aug 2015 17:10:38 +0000
From: Andrei Popov <>
To: Ilari Liusvaara <>
Thread-Topic: [TLS] Commentary on the client authentication presentation slides
Date: Mon, 10 Aug 2015 17:10:38 +0000
Message-ID: <>
References: <20150720141036.GA32204@LK-Perkele-VII> <> <> <> <20150801084849.GA7162@LK-Perkele-VII> <> <20150802182908.GA29836@LK-Perkele-VII> <> <20150808090351.GA14947@LK-Perkele-VII>
In-Reply-To: <20150808090351.GA14947@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; BLUPR03MB1393; 5:WrzIG0XeiD3MKp9bdeWGMiCb03dFVSckwANpqLubnRsYXRJ/0WA7iR7tdWUkvOpZt11rDMcPixjdb4OHzn6Ueq/QP/h/+lTTl6SnmN9G1StFrXagSCjAuknsUUJa5Im/WdAQr7lNuA0cQDV45zUklA==; 24:25jVUQ3o3PgzbC8oqG3SguZBFkOz/BAmSczsQGD1d9d4AFYNN5msKL0jGEU3WC+sJitQH9HRQgvpUDhPXPjiqHQpyWJ7GkHCT9F6Rmhuq9s=; 20:WHyI9NXFjl/AcKPTVKb3cHQPOWDRe7ofK+eBtkQ2E365Mdseyga51sbVRE3ma/V/OZi2ne397TVaozBZBLyY8w==
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB215;
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:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393;
x-forefront-prvs: 06640999CA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(189002)(24454002)(199003)(19580395003)(10400500002)(68736005)(5001830100001)(97736004)(5002640100001)(5001860100001)(54356999)(74316001)(40100003)(189998001)(5005710100001)(8990500004)(76176999)(10290500002)(110136002)(81156007)(122556002)(101416001)(4001540100001)(62966003)(77156002)(99286002)(2950100001)(105586002)(76576001)(92566002)(50986999)(64706001)(5001920100001)(5001960100002)(46102003)(2656002)(87936001)(19580405001)(5003600100002)(77096005)(102836002)(86612001)(106356001)(86362001)(106116001)(33656002)(10090500001)(2900100001)(93886004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( 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-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2015 17:10:38.8679 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393
X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB215; 2:9qvr8LuGYSUvEqXrOUI53FvxBL9hmc9pYV7AIo7AjSPLbZdZtGrEHq6bgbdz34f5RJqsXQbx6llKn82H+vXpe2FQfjYJgoBHtTwIBvUQOxb230ZorYW7tTWjQNOFM5jLf6TeM7phKbYoXSzOY+X8nw8nlGayXzyirDN4FxUnHz0=; 3:RrpN208Bi/dh4acx++LLXKJdDRQ+9u6tvNRRXCffoP/NJZzHakAIBqarlTH2WHlPQoYtU+bhwAlqDH4x10rwpaz/vaMI9lFdXDpcPtwcaoamKGHgwvqv5/HgB9jPrRaOyTk4ySOrh2SAbiGSo5rs+Q==; 25:zi/cBDZ9CJe30o/NeHNYUHpNW1PtJ3EwBFPLGt9hBNyjJGV//Nm9A/qr2/Meq+TPnwZ87rOgpbSrDUL7sk/xrmR2RJB8IKlnCjrjd/JhqCRr4XZTKu/HI/7W8rtZdHybtaaEup2udjOXKZrrPtun9ve+TeWSAahf1MknCEPljLHiZlg+H2ZKKkhUyOVa343IZpeQLaZU8cYYwSSx92SCc64uOvwntULqcfS7YnnJvfSI0kRn2mk4DbmTNLTlNJm2Bp/JNC+ltC9YbbsfiXfnmw==; 23:FOfSyjMMypaTPCEiZS8swooq8YD5PJnGpD8gujwrie63+qaWoy6k1khtaMkPf//u6pBLu6TzS4CkfiQsoJM6zt9U9edt/XkidG9buAE5yhdAbLAHWaL0latS78P3IbpZTm4hOK4dwLAZDyxMNtTzAOwpB3NjiizJIP8ZguZjXAQketYcDpPdZV60xcCSiUCd
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: Mon, 10 Aug 2015 17:10:43 -0000

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.

> Where's the capability for client to unilaterially decide to send a certificate without valid configuration?
My pull request is designed to address client auth in the middle of a TLS connection, after the handshake is complete, which is an existing scenario that was broken by the removal of renegotiation in TLS 1.3.
If enough people want the capability for the client to volunteer a certificate, I don't mind adding this to my pull request. Right now I don't have a sense of how useful WG participants think this would be.



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

On Tue, Aug 04, 2015 at 12:37:47AM +0000, Andrei Popov wrote:
> > 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.

What sort of usecase you have in mind for this? I can't come up with single one that I don't think is a hack at best.

Note: It is very easy to misuse capability like this (even if it is restricted to work only once per connection) to create nasty security issues (one example being trying to use this for HTTP/2 in browser environment).

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

Where's the capability for client to unilaterially decide to send a certificate without valid configuration? The 0-RTT certificate authentication requires a valid configuration.

E.g. one way to implement that would be certificate_request_request extension, which would request server to send a CertificateRequest.

Tho with the changes to always sign the key exchange, using 0-RTT client certs doesn't work unless the server requested certificates back then.

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

That was given as second of two entries in list of kinds of authentication I think are useful (and precluding it would mean removing TLS-Unique and TLS-Extractor, which is something that I really don't see happening).