Report on preliminary decision on TLS 1.3 and client auth

Martin Thomson <> Wed, 23 September 2015 17:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 686D21A8706 for <>; Wed, 23 Sep 2015 10:24:35 -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 0ebHyFKD2L6P for <>; Wed, 23 Sep 2015 10:24:33 -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 5247C1A872E for <>; Wed, 23 Sep 2015 10:20:51 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZenfR-0006mg-4H for; Wed, 23 Sep 2015 17:17:17 +0000
Resent-Date: Wed, 23 Sep 2015 17:17:17 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZenfK-0006lu-DF for; Wed, 23 Sep 2015 17:17:10 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZenfI-0005o1-Mf for; Wed, 23 Sep 2015 17:17:10 +0000
Received: by ykdz138 with SMTP id z138so48317122ykd.2 for <>; Wed, 23 Sep 2015 10:16:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zuJyQuqF4gwKla/gaJB/hLq2edlzIvj65RCLIkN5q28=; b=aNXcRwn4ZI3GBCWdeI0lMu/LcIfMQcALQpyJryR/ao/Kv6tj0aWlWa4d0eEoANfvXG 6kOr0aR173it3rKirR/1uJensepsZTDcCmQCTOMU5OLRwxZNxaekmoG1N+Jh35OwcA7t Zd3izgL+BePeWf3/a6dbMan6P9XpUs6gTgmh/t+7wiHk2T/bT2W6lnGObj86Vf8+jzCA rDuJCzPXzsBx/hedoJG7yXe4QIqRDf50NoXMd8n2iJFZCqljUSaPJF5ageMpImOmGGlX pjpGK5VnW6WzMpZ5SSX7Eo4q5+tNcDNYEhBYfPDLd0VXtDAuvpy//gaspkQCGmJbNqJl FPkA==
MIME-Version: 1.0
X-Received: by with SMTP id g188mr28040506ywe.52.1443028602311; Wed, 23 Sep 2015 10:16:42 -0700 (PDT)
Received: by with HTTP; Wed, 23 Sep 2015 10:16:42 -0700 (PDT)
Date: Wed, 23 Sep 2015 10:16:42 -0700
Message-ID: <>
From: Martin Thomson <>
To: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="94eb2c0763423ddd0005206d471a"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: AWL=1.842, 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_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1ZenfI-0005o1-Mf c1e74075b1961296814996584769d018
Subject: Report on preliminary decision on TLS 1.3 and client auth
Archived-At: <>
X-Mailing-List: <> archive/latest/30263
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

The minutes of the TLS interim have been posted. Some decisions regard
client authentication were made.

Here is a summary of the applicable pieces, plus what I options it provides

(Caveat here: aspects of this could change if new information is presented,
but it seems unlikely that there will be changes that will affect the core
The big change is that a server can request client authentication at any
time. A server may also make multiple such requests. Those multiple
requests could even be concurrent.

The security claims associated with client authentication require more
analysis before we can be certain, but the basic idea is that
authentication merely provides the proof that a server needs to regard the
entire session to be authentic. In other words, client authentication will
apply retroactively. This could allow a request sent prior to
authentication to be considered authenticated. This is a property that is
implicitly relied on for the existing renegotiation cases and one that we
might want to exploit.

Each certificate request includes an identifier that allows it to be
correlated with the certificate that is produced in response. This also
allows for correlating with application context. This is what I think that
we can use to fix HTTP/2.

Clients cannot spontaneously authenticate, which invalidates the designs I
have proposed, however, the basic structure is the basis for the first
option that I will suggest.

Option 1 uses a new authentication scheme. A request that causes a server
to require a client certificate is responded to with a 4xx response
containing a ClientCertificate challenge. That challenge includes an
identifier.  The server also sends - at the TLS layer - a
CertificateRequest containing the same identifier, allowing the client to
correlate it's HTTP request with the server's CertificateRequest.

  :method = GET ...

  :status = 401
  authorization = ClientCertificate req="option 1"

CertificateRequest { id: "option 1" }

Certificate+CertificateVerify { id: "option 1", certificates... }

  :method = GET ...

  :status = 200

Option 2 aims to more closely replicate the experience we get from
renegotiation in HTTP/1.1 + TLS <= 1.2.  Rather than rejecting the request,
the server sends an HTTP/2 frame on the stream to indicate to the client to
expect a CertificateRequest. That frame includes the identifier.

  :method = GET ...

  id = option 2

CertificateRequest { id: "option 2" }

Certificate+CertificateVerify { id: "option 2", certificates... }

  :status = 200

In this case, the server probably wants to know that the client is willing
to respond to these requests, otherwise it will want to use
HTTP_1_1_REQUIRED or 421.  So a companion setting to enable this is a good
idea (the semantics of the setting that Microsoft use for renegotiation is
pretty much exactly what we'd need).

I think that the first option has some architectural advantages, but that
is all.  The latter more closely replicates what people do today and for
that reason, I think that it is the best option.

As for how to implement this same basic mechanism in TLS 1.2, I have an
idea that will work for either option, but it's a bit disgusting, so I'll
save that for a follow-up email.