Re: [TLS] HTTP, Certificates, and TLS

Mike Bishop <> Thu, 21 July 2016 17:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0514C12D7D5 for <>; Thu, 21 Jul 2016 10:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Status: No, score=-2.003 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VJFnwCMCVg-I for <>; Thu, 21 Jul 2016 10:14:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D12CE12D7D4 for <>; Thu, 21 Jul 2016 10:14:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qPUOy+zaMEfZ/F5tKSH/dS/5Kasg64dwYNp02/BUHCQ=; b=LjCoX4rYKWUrjqlV8Z/yZhAfLh+0FC3BRayK4dS2IzCLzdG79zi9eY+RVpPsRh4TvC/m1KLaBw7s2MB3wqHAusdvkv1b5HSFCJj8cBKmG5ptS5VhxJ5yAR/UManivVrvgZjPWotycSbravtygBh4D3gkDw0TbtlV04cqFMOf87M=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.539.14; Thu, 21 Jul 2016 17:14:22 +0000
Received: from ([]) by ([]) with mapi id 15.01.0544.014; Thu, 21 Jul 2016 17:14:22 +0000
From: Mike Bishop <>
To: "" <>, Martin Thomson <>
Thread-Topic: [TLS] HTTP, Certificates, and TLS
Date: Thu, 21 Jul 2016 17:14:21 +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: [2001:67c:370:136:196b:abb1:c6e0:27a3]
x-ms-office365-filtering-correlation-id: 09b57e60-8e82-4810-23e7-08d3b18a7543
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1329; 6:q3Y/v1PFgD7qYiIs8RkZO+W23McPt3Y8FhOH7eXiP0sXn07wyX58Jlp8BQxTrum/5JsNjPpXtBy0pZo86tnr5GPZd1uHM+ZKCqny3VjhOxGOCMJjHAEvKze88O8QbEisuV4lvN8VvJ/RTDqzLQ9hkwaaXbMfPZNoH1wM2uqNJp8fUIazXYk7jSbp0goORaPB1FYfQzJUD2q+/AxOccBUAwqCfsIv9jZHdEevu//7hFM5Dyo9C5KlD9ClYvEVz9dOSG6Xq1eBBsktE4SczQKVfX25PQok6i8jqx36M8yVGzjPvILAGStCjKtKCrJJdeGB5vX7CVZ5Czf+q6qkK97gXg==; 5:5/KKaOn25IelqRdpmUrgKQPBYP+iwjjRhnXVO/+bT6xQmK4GaQ1mMuJ4hR6rCwwzcKx3RNDMk1yfgT3GMPK9dQlTg94cu38MpCbqIVgKy2AeHKczcQ76obZ5UNK7OQZRlwSSlgRYmFD21T5OSbdylw==; 24:+ecDcHytxXjzt03EF7gp0vvnb7AXlzHaklndSR+N2+s3kuSGI9ueSyq1qJs8S4lUjSGZ2YSzH7tac0qAX68VJ6zaicNyC7fQIPGv84xCoCs=; 7:3cw/UERtFOcc8sTT5y9afIjPWZMb/dgW7Fd3Iwy088lOsq8jsf/4+TwPxLWWDNwoKmOCLKMpN0ABm4xTVj4G31dlv6JyBzA846y2GHWh+HFYiHnEJ7OGA8w5nmF/2u8gX/ADrZVJEckpBIKWticcqiIN2LNWk/e0M3Z3tB2YVUCuM3+7nZLFcQx6bylAa+jQgQQU5h0KeZU+zFrI7GHT9PnV6dJW2/9viLnypSA8+GXqm7Q76b9LYMAcnlPJWelR
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1329;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(55761251573089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BLUPR03MB1329; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1329;
x-forefront-prvs: 0010D93EFE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(13464003)(189002)(199003)(24454002)(7736002)(8990500004)(86362001)(10400500002)(8666005)(5003600100003)(19580405001)(5005710100001)(7846002)(102836003)(6116002)(3660700001)(10290500002)(10090500001)(5002640100001)(122556002)(3280700002)(7696003)(74316002)(305945005)(2906002)(76576001)(11100500001)(4326007)(106356001)(19580395003)(586003)(105586002)(77096005)(2950100001)(2900100001)(97736004)(2501003)(86612001)(99286002)(33656002)(8936002)(68736007)(87936001)(54356999)(76176999)(81166006)(92566002)(50986999)(9686002)(5001770100001)(81156014)(101416001)(8676002)(561944003)(189998001)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1329;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2016 17:14:21.9478 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1329
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] HTTP, Certificates, and TLS
X-Mailman-Version: 2.1.17
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: Thu, 21 Jul 2016 17:14:27 -0000

That argument seems like it would apply to all post-handshake authentication, unless there's something different about that.

-----Original Message-----
From: Martin Rex [] 
Sent: Thursday, July 21, 2016 7:08 PM
To: Martin Thomson <>
Cc:; Mike Bishop <>om>;
Subject: Re: [TLS] HTTP, Certificates, and TLS

Martin Thomson wrote:
> On 21 July 2016 at 18:41, Martin Rex <> wrote:
>>    A server that implements this extension MUST NOT accept the request
>>    to resume the session if the server_name extension contains a
>>    different name.  Instead, it proceeds with a full handshake to
>>    establish a new session.
> If that's the only barrier to doing this, I'd be surprised.  The 
> prospect of having to overcome this is not at all daunting.

No, that is only the tip of an iceberg, and you're going Titanic here.

Really, this is about TLS session cache management (which is something very close to TLS) vs. Endpoint identification, i.e. interpreting end-entity certificates -- which is something that is explicitly outside of the scope of TLS (e.g. rfc2818 and rfc6125).

Could you please describe the approach to session cache management that you're conceiving here?  In the original TLS architecture (up to TLSv1.2) TLS sessions are read-only after creation, and identities (certificates) are locked down.  Forgetting to cryptographically bind the communication identities into the session properties allowed the triple-handshake-attack.

If you want to change any session properties (including certificates), you MUST perform a new full handshake, which creates a new session with new properties and a new session ID / session cache entry.

Session resumption (and session resumption proposal) should operate based on requested properties (is there an existing session with the requested properties?) and this is conceptually independent from the app-level endpoint identification (such as rfc2818/rfc6125).

The wording in rfc6066 is not optimal.  It should have better said:
whenever a full handshake would result in selection of a different server certificate, then the server MUST perform a full handshake, in order to produce predictable/deterministic behaviour that is not side-effected by session cache management / session cache lifetime effects.  The principle of least surprise.