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

Ilari Liusvaara <> Tue, 11 August 2015 05:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4F3F81A00A7 for <>; Mon, 10 Aug 2015 22:00:47 -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 gExjmYtWuBJv for <>; Mon, 10 Aug 2015 22:00:45 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 59DF01A009B for <>; Mon, 10 Aug 2015 22:00:44 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id 21D301A26D3; Tue, 11 Aug 2015 08:00:40 +0300 (EEST)
Date: Tue, 11 Aug 2015 08:00:40 +0300
From: Ilari Liusvaara <>
To: David Benjamin <>
Message-ID: <20150811050040.GA4729@LK-Perkele-VII>
References: <> <20150801084849.GA7162@LK-Perkele-VII> <> <20150802182908.GA29836@LK-Perkele-VII> <> <20150808090351.GA14947@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: Tue, 11 Aug 2015 05:00:47 -0000

On Mon, Aug 10, 2015 at 07:33:53PM +0000, David Benjamin wrote:
> Why not do this using HTTP's own auth framework? Have the client sign
> something which includes a channel binding, placing it and the certificate
> chain in an Authorization header. You could even transition to it in TLS
> 1.2 deployments, provided EMS is negotiated. When TLS 1.3 and EMS are not
> negotiated, fall back to the legacy thing.

Yeah, that would be much cleaner (and indeed was one[1] of the two ways
I think HTTP/2 client auth can be done without gross hacks).

Except that because for clean operation HTTP needs request-level
authentication, one would have to transmit the authentication
on each request (fortunately, on subsequent retransmits, it
can be compressed very well[2]).

[1] The other would be signaling via HTTP 401 and using that to
trigger new connection with client-driven client auth.

[2] Unless the payload needs internal nonces (and I don't think
it does), one can assume the same certificate on the same connection
always generates the same cert+signature block (if using deterministic
signatures, that happens even if one tries to sign again).