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

Eric Rescorla <ekr@rtfm.com> Mon, 25 May 2015 17:53 UTC

Return-Path: <ekr@rtfm.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 F09691A8A95 for <tls@ietfa.amsl.com>; Mon, 25 May 2015 10:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 sY1nzPoPRGsA for <tls@ietfa.amsl.com>; Mon, 25 May 2015 10:53:33 -0700 (PDT)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (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 316BE1A8A10 for <tls@ietf.org>; Mon, 25 May 2015 10:53:33 -0700 (PDT)
Received: by wichy4 with SMTP id hy4so55609402wic.1 for <tls@ietf.org>; Mon, 25 May 2015 10:53:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/E6cFa+zDnwgaDJn7a4a/bmKPZuUspf035H11Lic7gE=; b=ZU1mLLtSe5l4afRZ7Wv11xi2yjJdNszgQ9Zu2TCyGbKm1gUUzGWjk1TfXAGPI4VLC1 8S6NHdvQUCB4ju8pxTJBbA7Rn5o7bsvOdyu7EgIkLlLJxyjG+JBOSQ7bnlfAuitN/ju0 cVWaXgv0feQp2w8X6UhMP794ia2bGhUo2kIQEXmZvsXSV6aXCCx/7zhZUFY8e/PLxZXR oWEQc5KuzxORB1+DBLWMi+dFA8wpoVcVMHIor6JW7knctsRR82iMomaDHj5AySwmwjTd HUGL/N2ySIt//zAxsNZq/Hy0onjstizMoxY931Sx4FGKVRdd36R8YMKGnDCnvvRtR3gj /HjA==
X-Gm-Message-State: ALoCoQlmq/GrFrHeAzrSWtFek8aQakTOKPUuXkJzLfRiIjZNwoqf+wbEIx/LkxWFTvk8QYJUjhmK
X-Received: by 10.194.59.79 with SMTP id x15mr24365177wjq.81.1432576411912; Mon, 25 May 2015 10:53:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.225.14 with HTTP; Mon, 25 May 2015 10:52:51 -0700 (PDT)
In-Reply-To: <66ECB7D5-19B1-429F-8FE2-464671672310@inria.fr>
References: <CABcZeBM9UGZoifzDZZ3METMJJHa1ueX9CdHiccYTDW5UVC3RrA@mail.gmail.com> <66ECB7D5-19B1-429F-8FE2-464671672310@inria.fr>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 25 May 2015 10:52:51 -0700
Message-ID: <CABcZeBOzkAuaau6mKEw3=-na3BvVkQ6B9n7A6spOd0RfczFVeA@mail.gmail.com>
To: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
Content-Type: multipart/alternative; boundary=047d7b8737ae2558670516ebb0f9
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/5LCPxw5NwTvq9mfP5pmuB3pJyQI>
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: Mon, 25 May 2015 17:53:36 -0000

This does seem pretty far-fetched... And note that if we just required a
complete handshake
at this point, that wouldn't create a total failure.

My vote would be that unless someone speaks up relatively soon, we should
require one
of the two options listed in my message (at MUST).

-Ekr


On Mon, May 25, 2015 at 10:45 AM, Karthikeyan Bhargavan <
karthikeyan.bhargavan@inria.fr> wrote:

> Right, there was discussion on this and here’s the current rationale.
>
> If the original handshake used the extended master secret,
> then even if the resumption handshake does not, it is still protected
> by the key derivation in the original handshake.
>
> The only situation when I can see this happening is when the resumption
> handshake goes to different
> endpoints than the original handshake (e.g. in WPA), but maybe someone on
> the list knows better whether the following is a reasonable use case.
>
> The client connects to an access point which forwards the (EAP-TLS)
> connection to the (Radius) server.
> The server speaks TLS + extended master secret and the client and server
> agree upon a master secret.
> The server installs the master secret at the access point, which itself
> does not support extended master secret.
> The client can now communicate directly with the access point,  and also
> resume (EAP fast reauth) connections directly with access points without
> the need to recontact the Radius server
>
> A similar scenario can perhaps be envisioned in cases where a server farm
> of front-ends directs initial connections to a powerful server that
> supports extended master secret, but resumption handshakes (via session
> tickets) can be handled by any (legacy) server.
>
> Far fetched?
> -K.
>
>
> On 25 May 2015, at 19:35, Eric Rescorla <ekr@rtfm.com> wrote:
>
> >
> >
> >
> >
> > I'm updating the NSS session hash implementation to conform to the new
> spec
> > and I see that it's very clear on what happens when you have a resumption
> > where the original handshake did not include the extension and the new
> one
> > does (thanks David and Martin)
> >
> >   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.
> >
> > However, it's less clear on what happens when the original handshake
> included
> > the extension and the new one does not:
> >
> >    o  If the new ClientHello does not contain the
> >       "extended_master_secret" extension, the server 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.
> >
> > This doesn't seem to distinguish between the two cases (original session
> > did and did not use the extension), but they seem different, since the
> > original session not using session hash is a common case (legacy) whereas
> > an extension->no extension transition is an anomaly. Note that the client
> > *is* required to send it, so I think there's a reasonably strong
> > argument that the server should require it.
> >
> > The two main options appear to be:
> >
> >     1. Fall back to a full handshake.
> >     2. Abort the connection
> >
> > The argument for the first appears to be interop. The argument for the
> > second appears to be that it's likely there is an error or a mid-flight
> > reconfiguration on the client (which seems not good). My mild preference
> > is for abort but I think it's important in any case that the draft be
> > clear.
> >
> >
> > Similarly, the text about the client side doesn't seem to draw this
> > distinction:
> >
> >       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.
> >
> > Because above the server is required to provide the extension when
> > resuming a session where the extension was negotiated, it seems like
> > we should require the client to fail in that case (that's the sense
> > of the MUST).
> >
> > I see there was some discussion on the list 3/10 but it was inconclusive.
> >
> > -Ekr
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
>