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

Ilari Liusvaara <> Sun, 02 August 2015 18:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E753E1A802E for <>; Sun, 2 Aug 2015 11:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CYctnzXy4xd2 for <>; Sun, 2 Aug 2015 11:29:11 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EB061A802A for <>; Sun, 2 Aug 2015 11:29:11 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id DCB8469996; Sun, 2 Aug 2015 21:29:08 +0300 (EEST)
Date: Sun, 02 Aug 2015 21:29:08 +0300
From: Ilari Liusvaara <>
To: David Benjamin <>
Message-ID: <20150802182908.GA29836@LK-Perkele-VII>
References: <20150720141036.GA32204@LK-Perkele-VII> <> <> <> <20150801084849.GA7162@LK-Perkele-VII> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
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: Sun, 02 Aug 2015 18:29:14 -0000

On Sun, Aug 02, 2015 at 03:38:00PM +0000, David Benjamin wrote:
> On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara <>
> 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

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