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

David Benjamin <davidben@google.com> Tue, 26 May 2015 17:31 UTC

Return-Path: <davidben@google.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 069201ACD8E for <tls@ietfa.amsl.com>; Tue, 26 May 2015 10:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7W5MfW3mxIP5 for <tls@ietfa.amsl.com>; Tue, 26 May 2015 10:31:38 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 F19AF1ACD74 for <tls@ietf.org>; Tue, 26 May 2015 10:31:34 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so64132418igb.1 for <tls@ietf.org>; Tue, 26 May 2015 10:31:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=OGuan3fZXxCEycfH1wFzzMdzfCZNAhV22XXga9nSqmA=; b=jgU31vT06aKk2fkQi+WcylXJNPdpP9RS+YUPyITqXMwcRrtCFQgTm2I8mw4Hl7o7qV nETj+eZLXEHGfEEgQC3wO0fDZ7FcREUl09XhT8dD8ZVCJHkNK820fdyg4SgJ6abj3xFs rD50N93RRmzn4hL2qGGiv6duSyYZPy4znUbDb08b6JIHkpQUj50xoIyni+34Sjs0dkND w/ii1LG4OUc5RMD5sanhCp75k5/vwwIicBsIkyblJsm/KfySW4bmECYUtNe/qSp+zQDr gDu0Mazh8nuDBgtsFy47v2Du0FkCA1BIpA4Be+xJE71090s9PMnwrDn0A+0/XT8BccP3 Lrjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=OGuan3fZXxCEycfH1wFzzMdzfCZNAhV22XXga9nSqmA=; b=JxLLOowHX5Icu8puS3P3tGyfP0A+qUkcDixD7Mi/EOWXcHEZz58T3TwcujgH9Lbtk1 /tRGmumC1FSgBXPjROq0aWnQrmP352azQJzKm1ethPpxYa6zIFBXzL+lljpA8Dg++JS9 aXqMMvKRDFpcXXssLFI40m6emJ767Zo6Yp2H+KDGwtdhuQThIv9fMYjoH0pzw0Rww2FN lu7RkCA0By8gWE/eSGNq0NO3+TLSF/RXGTlNHeuOxtRs1MM4WPjQT50WB+4JrU16tpKD qngdf1WTytL5bRE4YpGTrtz85zy1kNcJVizSS5HEcSZPtMLMsIwAw5OuJuA4X0PFDd90 sfHw==
X-Gm-Message-State: ALoCoQmkICZAQ654Zc2/diL7gheXzIa0oTIBomyWu/s27Wt/mLeZpKe3veSAdQ36jmIFGg7y+K1e
X-Received: by 10.107.136.197 with SMTP id s66mr37275769ioi.65.1432661493287; Tue, 26 May 2015 10:31:33 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBM9UGZoifzDZZ3METMJJHa1ueX9CdHiccYTDW5UVC3RrA@mail.gmail.com> <CABkgnnVYu-YVQ9WkV_pi8R94dAmXSC9FrJ37iFRV=E4OxJyHTg@mail.gmail.com> <065E8B97-8EA0-4C6B-84B4-955648C329BE@inria.fr> <20150526072724.GA9576@LK-Perkele-VII> <30048D6E-80C0-4E3C-9336-DDA7C9121ABF@inria.fr> <20150526084216.GA10009@LK-Perkele-VII> <CAF8qwaCHA4NNRrbHFot+EpVxvYQ6HExDciZ3eB=2MXss-7bGFg@mail.gmail.com> <20150526165602.GA5805@LK-Perkele-VII>
In-Reply-To: <20150526165602.GA5805@LK-Perkele-VII>
From: David Benjamin <davidben@google.com>
Date: Tue, 26 May 2015 17:31:32 +0000
Message-ID: <CAF8qwaAmZnDE0m+Kb3+idCd2ruL-9o5Syqff3+kJrF9cB9wxsg@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: multipart/alternative; boundary=001a113ec878643b850516ff7ff8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/pHrRXezbNSXmvlfIhTAdd9J-bzw>
X-Mailman-Approved-At: Wed, 27 May 2015 05:31:49 -0700
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: Tue, 26 May 2015 17:31:40 -0000

On Tue, May 26, 2015 at 12:56 PM Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> On Tue, May 26, 2015 at 04:41:37PM +0000, David Benjamin wrote:
> > On Tue, May 26, 2015 at 4:42 AM Ilari Liusvaara <
> ilari.liusvaara@elisanet.fi>
> > wrote:
> >
> > > Could the scenario I gave (quoted below) happen in practice (it causes
> > > resumption of session_hash-enabled session with non-session_hash
> server)?
> > >
> > > > > I was thinking latter of those odd behaviours could occur if one
> > > performs
> > > > > rolling security fix of server farm:
> > > > > - Client is security fixed
> > > > > - Server A is security fixed
> > > > > - Client connects to A
> > > > > - Client gets session_hash-enabled session.
> > > > > - Client connects to B, attempting to resume.
> > > > > - Servers share session DB/key, so resumption succeeds.
> > > > > - Client gets resumption without session_hash extension.
> > >
> >
> > This could certainly happen with a server farm, yeah. Hopefully such a
> > situation would be rather transient, and it can be mitigated by sharding
> > the session cache between EMS-less and EMS-ful halves of the rollout. But
> > relying on it always happening seems unrealistic, so honoring the SHOULD
> is
> > a little risky.
>
> IIRC, this hits MUST. That is, the client is REQUIRED to abort in this
> case.
>

I don't think it does. The text is:

   o  If the original session did not use an extended master secret but
      the new ServerHello does contain the "extended_master_secret"
      extension, the client MUST abort the handshake.

   o  If the new ServerHello does not contain the
      "extended_master_secret" extension, the client SHOULD abort the
      handshake.  If it continues with an abbreviated handshake in order
      to interoperate with legacy peers, then the considerations in
      Section 5.4 apply.

The latter applies if an EMS-less server resumes an EMS-full session. This
is what you described. The former applies if an EMS-full server resumes an
EMS-less session. That one shouldn't cause interop problems assuming all
EMS-full servers honor this MUST:

   o  If the original session did not use an extended master secret but
      the new ClientHello does contain the "extended_master_secret"
      extension, the server MUST NOT perform the abbreviated handshake.
      Instead, it SHOULD continue with a full handshake to negotiate a
      new session.

Whereas an EMS-less server may be able to parse a serialized EMS-full
session and attempt to resume it. (In the case of OpenSSL, even if the
structure version gets bumped, d2i_SSL_SESSION kindly ignores the version
field because why not[*]? Though I suppose the structure's syntax could
just get changed incompatibly to break the parse.)

David

[*] I believe the rewrite of that code in the master branch will actually
check it, but 1.0.2 and before don't.