Re: [TLS] More clarity on resumption and session hash

Adam Langley <agl@imperialviolet.org> Wed, 03 June 2015 22:20 UTC

Return-Path: <alangley@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C975E1B3002 for <tls@ietfa.amsl.com>; Wed, 3 Jun 2015 15:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdbOY5Zs9J2s for <tls@ietfa.amsl.com>; Wed, 3 Jun 2015 15:20:53 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EB31B2FFF for <tls@ietf.org>; Wed, 3 Jun 2015 15:20:53 -0700 (PDT)
Received: by labpy14 with SMTP id py14so19025877lab.0 for <tls@ietf.org>; Wed, 03 Jun 2015 15:20:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Cf8QsoArEvkSoB3UEDwk4r9H/h7zW5socnDuWCcGCrQ=; b=DiLN6GyofPIz7Cild74T1xF2jIo/qGtC63qtzmHnyn3NbRsV1cKjFDvIqz57Nm82V1 mrBaLgbjay8IWek0aZrg3zh5YluBuwJuCIa9DSdpT49llwP5D1209DD+LsWRw1cQW7g4 Ln8P/8wdmiM3jyqbzM+urzldlprK0dsJkLoqQOmb/RQT+NkVpuI355eOKxACC1Oq00ge 1avSKYvVRM3QTDJiBbFK5sQf8UCYoueBxiE9t1YmsNt4eIwpL0MtBmXQeRoEKH/IpMgx rp8NNkj/DRr1kikwQQIVTpSkzzOyxl1nwuzRYOzuXSKh39+3Vnd28/CLY5IiakZPVxZO FK+A==
MIME-Version: 1.0
X-Received: by 10.112.220.7 with SMTP id ps7mr33707374lbc.72.1433370051665; Wed, 03 Jun 2015 15:20:51 -0700 (PDT)
Sender: alangley@gmail.com
Received: by 10.112.89.69 with HTTP; Wed, 3 Jun 2015 15:20:51 -0700 (PDT)
In-Reply-To: <CAF8qwaAU9VXuBPTgffJ+7VHLspGCi8Jp6h6-4+Rk2zyF9p8R-A@mail.gmail.com>
References: <CABcZeBM9UGZoifzDZZ3METMJJHa1ueX9CdHiccYTDW5UVC3RrA@mail.gmail.com> <20150527172329.GI27628@localhost> <CABkgnnUb5jDMMchxDxun_Kp9hYJ8_YFK_URrE=bXE8oej=zYCA@mail.gmail.com> <CABcZeBO6=V8HFTnr82_tt63HQiwSjeSJ-o-hS3sr_tUnO-Jy5g@mail.gmail.com> <CAF8qwaBori2QARe4Xz0aoV2OnQoyXvxGYT03YFvSwGeC9eRZUw@mail.gmail.com> <f7a4a15a0d5d4c859be1193ce5dcd313@ustx2ex-dag1mb2.msg.corp.akamai.com> <CAF8qwaB5dqfgvzNduDtjerBKf2Uk=YMcoy+m0nW2zp-idmcj+g@mail.gmail.com> <CAF8qwaAU9VXuBPTgffJ+7VHLspGCi8Jp6h6-4+Rk2zyF9p8R-A@mail.gmail.com>
Date: Wed, 03 Jun 2015 15:20:51 -0700
X-Google-Sender-Auth: _3A4pKj3mneTWHnJPXzHN75DbLE
Message-ID: <CAMfhd9WqTOWLxLO5VksZZZEc+EQDiUBcsJVQpUCrRVbrm-cptA@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
To: David Benjamin <davidben@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/6d0whKEp17umgbOLGcjd0wLx3Mc>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 22:20:54 -0000

I've landed a change[1] in BoringSSL which enforces connection aborts
in three cases:
 a) as a client: a session without EMS is resumed with a ServerHello
that supports it.
 b) as a server or client: a session with EMS is resumed on a
connection without EMS negotiated.

It also causes servers not to resume sessions without EMS if the
client offers EMS in the resumption ClientHello.

Chrome will implement these behaviours in a future version and
hopefully that's enough to ensure good behaviour in the ecosystem as a
whole.

[1] https://boringssl.googlesource.com/boringssl/+/ba5934b77f0058dc963b075e0ec1f401a24c0b2b


Cheers

AGL