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

Ilari Liusvaara <> Sat, 01 August 2015 08:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 993B51B2C05 for <>; Sat, 1 Aug 2015 01:48:55 -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 jzhyTwH000vr for <>; Sat, 1 Aug 2015 01:48:53 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A3F01B2B63 for <>; Sat, 1 Aug 2015 01:48:52 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id D144D699EE; Sat, 1 Aug 2015 11:48:49 +0300 (EEST)
Date: Sat, 01 Aug 2015 11:48:49 +0300
From: Ilari Liusvaara <>
To: David Benjamin <>
Message-ID: <20150801084849.GA7162@LK-Perkele-VII>
References: <20150720141036.GA32204@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: Sat, 01 Aug 2015 08:48:55 -0000

> On Tue, Jul 28, 2015 at 6:28 PM David Benjamin <> wrote:
> > Are you intending that this mechanism be enabled by default for HTTP/2 or
> > would the prohibition against renego still apply? Without any way for the
> > client to tie the CertificateRequest to the HTTP request that triggered it,
> > this mechanism would have many of the same problems as renego as far as
> > HTTP/2 is concerned. (I realize Microsoft has a draft floating around for a
> > TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this too I
> > suppose.)

Even if there would be way to tie it to request that triggered the request,
it would still IMO have some of the nastiest problems of renegotiation,
especially in context of HTTP/2 in web (the privilege involved is almost
impossible to handle in any sane way).

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.

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