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

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Tue, 26 May 2015 16:56 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 C31BC1B2C7A for <tls@ietfa.amsl.com>; Tue, 26 May 2015 09:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 jbhBcqB2sset for <tls@ietfa.amsl.com>; Tue, 26 May 2015 09:56:05 -0700 (PDT)
Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5791AC3C1 for <tls@ietf.org>; Tue, 26 May 2015 09:56:05 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id DDF363FE3; Tue, 26 May 2015 19:56:02 +0300 (EEST)
Date: Tue, 26 May 2015 19:56:02 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: David Benjamin <davidben@google.com>
Message-ID: <20150526165602.GA5805@LK-Perkele-VII>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAF8qwaCHA4NNRrbHFot+EpVxvYQ6HExDciZ3eB=2MXss-7bGFg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/chv2TIujePnuU4eZzt8WcipjjDI>
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:56:08 -0000

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 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.

AFAIK:

If you don't resume, TLS-Unique is fine. TLS-Extractor is not.

If the original connection had EMS, then both TLS-Unique and TLS-Extractor
are fine, regardless of if resumptions do.


-Ilari