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

Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr> Tue, 26 May 2015 08:05 UTC

Return-Path: <karthikeyan.bhargavan@inria.fr>
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 09D5A1B2A34 for <tls@ietfa.amsl.com>; Tue, 26 May 2015 01:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level:
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 mq8DlFgWiB25 for <tls@ietfa.amsl.com>; Tue, 26 May 2015 01:05:07 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905BD1B2A33 for <tls@ietf.org>; Tue, 26 May 2015 01:05:06 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.13,497,1427752800"; d="asc'?scan'208";a="155045492"
Received: from wifi-auth-191208.inria.fr ([128.93.191.208]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 26 May 2015 10:05:05 +0200
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9935C8F3-05CC-4C37-974A-3C4D5C2B886C"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
In-Reply-To: <20150526072724.GA9576@LK-Perkele-VII>
Date: Tue, 26 May 2015 10:05:04 +0200
Message-Id: <30048D6E-80C0-4E3C-9336-DDA7C9121ABF@inria.fr>
References: <CABcZeBM9UGZoifzDZZ3METMJJHa1ueX9CdHiccYTDW5UVC3RrA@mail.gmail.com> <CABkgnnVYu-YVQ9WkV_pi8R94dAmXSC9FrJ37iFRV=E4OxJyHTg@mail.gmail.com> <065E8B97-8EA0-4C6B-84B4-955648C329BE@inria.fr> <20150526072724.GA9576@LK-Perkele-VII>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Ox7XPWPLBC5bwlNbLC6fvBksjm8>
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:05:09 -0000

> 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.
We use SHOULD NOT for these cases; after being advised that MUST NOT is too strong for legacy interop.

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

The question is whether these could happen in practice, and I would welcome more thought son that.
-K.


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