Re: Client Certificates - re-opening discussion

Yoav Nir <> Sun, 20 September 2015 21:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 382521A8AB5 for <>; Sun, 20 Sep 2015 14:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OebKae1m4Jkp for <>; Sun, 20 Sep 2015 14:52:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 676E51A8A91 for <>; Sun, 20 Sep 2015 14:52:54 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZdmUV-00063I-C7 for; Sun, 20 Sep 2015 21:49:47 +0000
Resent-Date: Sun, 20 Sep 2015 21:49:47 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZdmUO-00062X-T1 for; Sun, 20 Sep 2015 21:49:40 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZdmUN-0004N9-Gu for; Sun, 20 Sep 2015 21:49:40 +0000
Received: by wiclk2 with SMTP id lk2so88603661wic.1 for <>; Sun, 20 Sep 2015 14:49:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TCwPbZwk4wcvk+pQKwQQ871UvzVccisHRelyMIe7yy4=; b=E+NKfNTyfURo2A4Svpbx4RjFZIWiMwFDxaQTlmEiV/U/2caXvseVJl+S3+TZyKs3i6 FS6ZFDlMHG+HwI8+bs5TAkRqNed+oSHz54F2n2+YF2IZpaVcpG1ibq9LQDMQrgx9xqv+ f1ua5MC7ddn8s6HCene92hUlmAmApQUe4IKbpdXFErLOkDSW78cANELD+Cuwve0J3izq SzZs/zi0PunVltE7CO1q6j399E+4OhPm9Q9q1Dm1QeGDKx/eLdpAT0AssoMbYXc/q8gL GlSy5tt0IMc+Smp1SECt9pyaKNM/8MPZ5rzrOnu4tzDex6JQ3wbOgcjdkjHlHsYWYT16 gcFQ==
X-Received: by with SMTP id k5mr10461746wiz.76.1442785752414; Sun, 20 Sep 2015 14:49:12 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id s16sm10172925wik.13.2015. (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Sep 2015 14:49:11 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_322C4033-AA5D-4B21-A0B0-8B76B95FA938"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Mon, 21 Sep 2015 00:49:08 +0300
Cc: Eric Rescorla <>, Stefan Eissing <>, Ilari Liusvaara <>, Mark Nottingham <>, Henry Story <>, HTTP Working Group <>
Message-Id: <>
References: <> <> <> <> <20150918205734.GA23316@LK-Perkele-VII> <> <> <>
To: Mike Bishop <>
X-Mailer: Apple Mail (2.2104)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.818, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ZdmUN-0004N9-Gu ea4ad725bed3b56224a5652fd62de790
Subject: Re: Client Certificates - re-opening discussion
Archived-At: <>
X-Mailing-List: <> archive/latest/30239
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi, Mike

> On Sep 20, 2015, at 1:10 AM, Mike Bishop <> wrote:
> Kind of a non-problem, but it’s also the problem itself.  The HTTP layer will call different APIs in TLS, but the API HTTP exposes (get client certificate) won’t necessarily change.
> ·        HTTP/1.x + TLS <=1.2 – Client certs work via renegotiation
> ·        HTTP/x + TLS 1.3 – Client certs work via new TLS feature that isn’t renegotiation
> ·        HTTP/2 + TLS 1.2 – How do client certs work?
> It’s a time-scoped problem, since we hope everyone will eventually be on TLS 1.3, but it’s a nearly-universal problem at the moment.  There are many proposed kludges for HTTP/2 over TLS 1.2 in the meantime, but we need to find something with broader support than any idea currently has.

I’m not sure I see how PR #209 solves the issue.

HTTP/2 prohibited renegotiation because HTTP/2 is non-sequential. A bunch of requests may be in process and it is non-deterministic which responses will be generated before, during and after the client authentication. One resource might trigger the renegotiation, but several others might receive different responses based on whether or not the user is authenticated.

Now suppose we replace renegotiation with the mechanism proposed in PR #209. Some resource triggers the TLS layer, but instead of triggering a re-negotiation by sending a HelloRequest, it triggers client certificate authentication by sending a CertificateRequest. This is different in some senses: there is no change to the master secret; the old channel bindings are still valid; session keys are not replaced. I don’t see what difference this makes. The connection still changes from a state where the client is anonymous to a state where the client is authenticated. Requests sent by the client still may have been responded to before, during or after the change of state. 

Maybe I’m missing something, but I don’t see what #209 does that renegotiation did not.