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

Mike Bishop <> Mon, 26 October 2015 18:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3E9881B504F for <>; Mon, 26 Oct 2015 11:03:36 -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 SKnYMPxkm24u for <>; Mon, 26 Oct 2015 11:03:34 -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 99E841B504E for <>; Mon, 26 Oct 2015 11:03:34 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1Zqm54-0007Rp-2B for; Mon, 26 Oct 2015 18:01:14 +0000
Resent-Date: Mon, 26 Oct 2015 18:01:14 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Zqm4z-0007R3-Ao for; Mon, 26 Oct 2015 18:01:09 +0000
Received: from ([] by with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1Zqm4w-0007IQ-JC for; Mon, 26 Oct 2015 18:01:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WEDvzfuOgN1kciBa/uUj6BHrWAXjqub4G/tXoPhB0xQ=; b=KLa5GB0rzkrxALpKCZ09zdXfst4pvFZCwPRtblSM8vYQIURI3YTsQC7wdA1c94mgy3oIiAJpf2dBZaHI/40HnutQmS6sKVewET8w/N3gE56dJTmqsNqqkVYNKXT6y5e19SOfSaRwN8nB2C+CnV1kmZ2tl3x5wU+NLWVajxsWsgQ=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.306.13; Mon, 26 Oct 2015 18:00:38 +0000
Received: from ([]) by ([]) with mapi id 15.01.0306.003; Mon, 26 Oct 2015 18:00:38 +0000
From: Mike Bishop <>
To: Yoav Nir <>, Martin Thomson <>
CC: "Jason T. Greene" <>, Ilari Liusvaara <>, HTTP Working Group <>
Thread-Topic: Report on preliminary decision on TLS 1.3 and client auth
Thread-Index: AQHQ9iREj/alLzU/z02s3MOmCNX3oJ5ziZaAgACKNACAAGZNgIAAXtaAgAizhgCAALZS4A==
Date: Mon, 26 Oct 2015 18:00:37 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; CY1PR03MB1376; 5:uJoLlYxLpI7Cm3NhRkyfc23yoYNjBu5LShu52NTA8KvkBPuFSGenEqURYJO3wgblFvqF3s/wIEqv7IfA7tfhpwacXMhJPvIB+uyryCSxX/NZ5oSv5+u1exYcepgjWMFBYB+yla2P+kCt5bLg7Wjn6A==; 24:jLH9SFVSIGoEER5vk0uqMK5s+qKLljU1KqNSxjfcNwa7PD54WZ8lLe1pacECVJZKE48M/w5AP0SggC6qVa3IYGfYQSov5epw911WwiWTFD0=; 20:ey60xxOaeWY9dBrAWZHUWUVYM5y9Vn8K1KXBWEoPn1LXlFwEINHVwKbX5LfGes2qwNDNm6A1eV2k9R+QuTdQOQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB1376;
x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay
x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(102215026)(61426024)(61427024); SRVR:CY1PR03MB1376; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB1376;
x-forefront-prvs: 0741C77572
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(377454003)(189002)(13464003)(86612001)(86362001)(40100003)(5002640100001)(2950100001)(101416001)(76176999)(93886004)(122556002)(50986999)(2900100001)(189998001)(5005710100001)(8990500004)(87936001)(5004730100002)(66066001)(54356999)(77096005)(10290500002)(10400500002)(5007970100001)(74316001)(5008740100001)(92566002)(19580405001)(10090500001)(106116001)(11100500001)(97736004)(102836002)(5001770100001)(81156007)(33656002)(106356001)(5001960100002)(105586002)(5003600100002)(99286002)(76576001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB1376;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2015 18:00:38.1648 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB1376
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: AWL=-2.567, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: 1Zqm4w-0007IQ-JC 0b8aa916fd3c25e579ec0273451c7a63
Subject: RE: Report on preliminary decision on TLS 1.3 and client auth
Archived-At: <>
X-Mailing-List: <> archive/latest/30404
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.