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

David Benjamin <davidben@google.com> Tue, 26 May 2015 16:41 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 69B711A92BB for <tls@ietfa.amsl.com>; Tue, 26 May 2015 09:41: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 Hv-6lWD7VqdJ for <tls@ietfa.amsl.com>; Tue, 26 May 2015 09:41:38 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 AAA6D1A92B4 for <tls@ietf.org>; Tue, 26 May 2015 09:41:38 -0700 (PDT)
Received: by igbsb11 with SMTP id sb11so57940224igb.0 for <tls@ietf.org>; Tue, 26 May 2015 09:41:38 -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=Joz2zb25K66Xp1onqAaNrNeYQS5fpERCo4PqsEe89Cw=; b=DcPfok8+p3p27kXfgLbiDL5TipoJ3s5eNW4dVc8tdVTdMS6oUtdYW8E9bxumeupdRM uVW/fWf5XfqLw+fghkZyIHayUGhkN+BNMbbTPeucxpqf6jKAXz3ZSJpH+boD5wXPLC6L 9u055jtZWfM5zcP0zDgmuaHjV50tLgt4SedevPoE5qEvd5Mi2vTJ0GhDen0TYho0Vv1E J5kqTfJabT67APBUwlCpE3xivLxAmuO8u5BELAEGl4hrdi0tyxuVhxqXt8I40RiDyahA oaHwfuQ/Khdj86pzCxreNmOXCG+2pDKnNp5/dokdEMqfpJLheyiCUBzjIqkK1r1YjiwO UoWQ==
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=Joz2zb25K66Xp1onqAaNrNeYQS5fpERCo4PqsEe89Cw=; b=f4T2I151BMjtoMrj+XK8wfCJECj7nr9lFvH7DRk10JTHz7om66Rjl5mW7gSG1oPABX ogNqA3t0R2fRsNBIJooAzn4X8OWyYCU7l/6IRe1gtTf3b+8xpK1FAVgiriGqlcNHRTW+ Uinb1f8FrfdBmjJdYAj4zzm5oaKFKaWkTht8wdovGZj+ks3xbbPeqXaf8df/Tlr9Jz0x bQj54PATYUWpPxzN3SpV4xcw/NsjorzkgRU5L9O312UGxeD6sGAtpj64V6ZjUFBB1pcY X2oCTPuLt1+DH4bgOPfKAhfJbrz/V6Rg6Q6HmvOdmazmsFdspDaupGVMei2CVuwuylcC 44hQ==
X-Gm-Message-State: ALoCoQm1ddm+DVY5/mN4mLDPCNpP5akFOKghSYZE+LLL/MxSIAobITHCWcvL5QsYJmMgLjXj2wwn
X-Received: by 10.43.59.80 with SMTP id wn16mr30518150icb.40.1432658498127; Tue, 26 May 2015 09:41:38 -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>
In-Reply-To: <20150526084216.GA10009@LK-Perkele-VII>
From: David Benjamin <davidben@google.com>
Date: Tue, 26 May 2015 16:41:37 +0000
Message-ID: <CAF8qwaCHA4NNRrbHFot+EpVxvYQ6HExDciZ3eB=2MXss-7bGFg@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
Content-Type: multipart/alternative; boundary=bcaec51dd23bddb02d0516feccd3
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/cXPwg8MYh91kg8_QyOnMpm3q5xE>
X-Mailman-Approved-At: Wed, 27 May 2015 05:31:43 -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 16:41:40 -0000

On Tue, May 26, 2015 at 4:42 AM Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
wrote:

> > > The following are odd edge cases (assuming both ends are due
> endpoints, these
> > > are safe):
> > > - Resume session_hash-enabled session wihout session_hash extension
> > > - Resume session_hash-enabled session with non-session_hash server.
> >
> > Indeed these are the cases that Ekr is objecting to.
> > In the current draft we say SHOULD NOT for these, and Ekr suggests it
> should be MUST NOT.
> > Formally, these cases are “safe” in the sense that they are protected by
> the extended master secret on the first handshake.
> > In practice, they are a bit weird because it looks like the connection
> security degraded between the two handshakes.
>
> AFAICT, if these can actually happen in practice, aborting does create
> interop problems.
>
> > The question is whether these could happen in practice, and I would
> welcome more thought son that.
>
> 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.

I would think tls-unique and friends are still fine in this case? Though if
we're worried about it (maybe we introduce some new extension later and
would rather it be incorporated into the key derivation?), we could just
say that the client should still disable tls-unique and whatnot. I.e.
IsTLSUniqueSecure() requires that BOTH the connection and the original
session, if any, are EMS-ful. That seems appropriately conservative and
without risk of (transient) interop failures. Client with require interop
need to account for that returning false anyway.

For the converse case (client offers an EMS-ful session on an EMS-less
connection, draft says server SHOULD abort), I can't think of a deployment
where this could happen in practice. The analogous "server farm" case seems
less likely for a client, so aborting seems fine. Still, I don't see a need
for the abort, so I would marginally prefer either "fall back to a full
handshake" (unlike the client, the server has this option) or "just behave
as you otherwise would and inherit whatever EMS-ful => EMS-less tls-unique
considerations we adopt above".

It's slightly confusing that the text tries to specify everything with a
single menu of SHOULDs to pick and choose. It's seems there's only two
profiles to worry about: "EMS required" and "EMS optional due to interop
needs". In fact, the two SHOULDs we're talking about don't even explicitly
talk about the EMS-ful session => EMS-less resumption case. They just say
to abort period, which is mostly for the "EMS required" profile.

David