Re: Report on preliminary decision on TLS 1.3 and client auth

Yoav Nir <> Wed, 28 October 2015 11:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5B8651B5221 for <>; Wed, 28 Oct 2015 04:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.012
X-Spam-Status: No, score=-7.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Xs3aQpAGYOcE for <>; Wed, 28 Oct 2015 04:39:11 -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 7875F1B521B for <>; Wed, 28 Oct 2015 04:39:11 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZrP1R-0001iG-Fn for; Wed, 28 Oct 2015 11:36:05 +0000
Resent-Date: Wed, 28 Oct 2015 11:36:05 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZrP1O-0001gA-8d for; Wed, 28 Oct 2015 11:36:02 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZrP1M-00074n-GA for; Wed, 28 Oct 2015 11:36:01 +0000
Received: by wmeg8 with SMTP id g8so6646085wme.1 for <>; Wed, 28 Oct 2015 04:35:33 -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 :content-transfer-encoding:message-id:references:to; bh=CsNJSQPwVdyM9Fm89NdytLC3xPmCo0oRZucyeQ0Z+0A=; b=y9rNCgVoRN593EbSf70QspAltYmmIjFIXK0+2REtlg/Sbsi8I+mjWU1oOT0DQGOAlg G6bcTHQCEAg+DSKalj4iy/6vDsNmYjY5BrJjKVaYCkQpKvCO/vccH9WuYXEFZ/BDlZ6d fUNVaU7KPK2HL+Yh1wcXkdnTM8fkRZ+fYLS3xJHIXrbZDdSMavRBtDiEeYK4FSD+Y2lb AixE7CD2MXKtU/WHCDADloBjp2L5+V6O710YjfKmaSFe3BARqytigTaqb1zuBRJBOieM 6taQUOMz1B/hfH8EFO+u+A+OvXG7b+Ejcio3Y5rqfZ2OKBJcxQbp0Gl07+DqJJ3tJGeN ydug==
X-Received: by with SMTP id i196mr1133957wmd.17.1446032133496; Wed, 28 Oct 2015 04:35:33 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id t126sm4300387wmd.18.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Oct 2015 04:35:32 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Wed, 28 Oct 2015 13:35:30 +0200
Cc: Martin Thomson <>, "Jason T. Greene" <>, Ilari Liusvaara <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Mike Bishop <>
X-Mailer: Apple Mail (2.3096.5)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: AWL=-1.083, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ZrP1M-00074n-GA e39d11eb8d1d6f47dea28b45ca62415b
Subject: Re: Report on preliminary decision on TLS 1.3 and client auth
Archived-At: <>
X-Mailing-List: <> archive/latest/30412
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I’m not sure I follow. As you say, existing apps call the HTTP layer requesting the client cert. The HTTP layer does some magic, which could be a TLS 1.2 renegotiation, a TLS 1.3 Certificate Request, or a new HTTP authentication. Either way, the HTTP layer finally returns to the application with either a certificate or a lack thereof.

Both ways, the app does not need to change. That’s a good thing. Why would we need to change the APIs?


> On 26 Oct 2015, at 8:00 PM, Mike Bishop <> wrote:
> Yes, the new thing would be "just" a new authentication mechanism, but the existing apps call down to the HTTP layer requesting the client cert, which asks TLS to either return or obtain the client cert.
> As Martin has said, there's no opposition to a cert-based, or key-based, HTTP auth protocol being defined.  That's definitely something beneficial to the Internet that people could move toward in the future.  However, in the short term, we have applications which rely on the existing APIs and mechanisms -- the goal with this draft is simply as a compatibility measure.  Currently, those applications cannot use HTTP/2 over TLS 1.2 without one of the various hacks; in TLS 1.3, it will be less hacky.
> You're arguing for a more idealized solution -- that's something I can get behind as a long-term direction, but we also have short-term issues that need a solution.  One does not preclude the other.
> -----Original Message-----
> From: Yoav Nir [] 
> Sent: Monday, October 26, 2015 12:03 AM
> To: Martin Thomson <>
> Cc: Jason T. Greene <>; Ilari Liusvaara <>; HTTP Working Group <>
> Subject: Re: Report on preliminary decision on TLS 1.3 and client auth
>> On 20 Oct 2015, at 9:10 PM, Martin Thomson <> wrote:
>> On 20 October 2015 at 05:31, Jason T. Greene <> wrote:
>>> Wouldn't the semantics be a hell of a lot cleaner, and implementations a lot simpler, if we just pushed this to an HTTP cert auth protocol?
>> Yes, yes it would.  A better authentication mechanism might be better 
>> still.  But that would be a new protocol.  We have plenty of evidence 
>> to suggest that a new protocol would not be acceptable.  As I said, we 
>> are already at plan B.
> An HTTP cert auth protocol is just an HTTP authentication method, much like Basic, Digest or the experimental ones we’re standardizing in http-auth. The framework is already there in all clients and servers.  It has the advantage that you don’t have to skip between protocol layers - it’s all in HTTP. This way the client is in control of which streams are authenticated and which are not, so Imari’s security hole could go away. 
> Practically you probably don’t want to sign each request, so applications are likely to set a cookie (or tokbind) after a single authentication and use that to continue the authentication to other resources, but that’s the way they do it with other forms of authentication anyway.
> Yoav