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

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Tue, 26 May 2015 08:42 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 3436B1A1ACC for <tls@ietfa.amsl.com>; Tue, 26 May 2015 01:42:22 -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 n3cbK2ckncGK for <tls@ietfa.amsl.com>; Tue, 26 May 2015 01:42:19 -0700 (PDT)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E1A1A1AA9 for <tls@ietf.org>; Tue, 26 May 2015 01:42:19 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 27AD4188830; Tue, 26 May 2015 11:42:17 +0300 (EEST)
Date: Tue, 26 May 2015 11:42:16 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
Message-ID: <20150526084216.GA10009@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <30048D6E-80C0-4E3C-9336-DDA7C9121ABF@inria.fr>
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/VLTUqB8emYJDBG80Eh3KFmDC2VI>
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 08:42:22 -0000

On Tue, May 26, 2015 at 10:05:04AM +0200, Karthikeyan Bhargavan wrote:
> > Also, there are two dangerous scenarios:
> > - You have non-session_hash session and resume that.
> > - You try to use TLS-Exporter in non-session_hase session for authentication.
> > 
> > Based on this, it would seem to be the safest to:
> > - Not offer any non-session_hash sessions for resumption.
> > - Deny resumption (full handshake) of any non-session_hash sessions, regardless
> >  of client session_hash support.
> > - Disable TLS-Exporter in non-session_hash sessions.
> 
> 
> It’s worth checking, but I believe these cases are covered in the spec.

The current spec seems to say:
- F->F: SHOULD abort
- F->T: MUST NOT resume (server), SHOULD NOT attempt resume (client)
- T->F: SHOULD abort (this is a weird case)
- T->T: (nothing)

> We use SHOULD NOT for these cases; after being advised that MUST NOT is too strong for legacy interop.

AFAICT, the first two still give interop, just with reduced performance
(full handshakes instead of resumptions).

The third breaks protocols that use TLS-Exporter, including just for keying,
which is seemingly not affected by THS unless one resumes (one can't expect
any security from bad connection).

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


-Ilari