[TLS] Interaction between session resumption and negotiated protocol version

Fabrice Gautier <fabrice.gautier@gmail.com> Fri, 03 April 2015 21:38 UTC

Return-Path: <fabrice.gautier@gmail.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 F264D1A1A42 for <tls@ietfa.amsl.com>; Fri, 3 Apr 2015 14:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ycXGR2r4ZVy1 for <tls@ietfa.amsl.com>; Fri, 3 Apr 2015 14:38:16 -0700 (PDT)
Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (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 839381A0193 for <tls@ietf.org>; Fri, 3 Apr 2015 14:38:16 -0700 (PDT)
Received: by obbgh1 with SMTP id gh1so177906476obb.1 for <tls@ietf.org>; Fri, 03 Apr 2015 14:38:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=uUV1CBScVxhtZsBukdFXPG4f9Z5tGgvnpdFGMaVv8fI=; b=twBPIsmxk1S3xIbxOrqPBxEYILdQEwXKM1Q1pma45QMmlujmzHeivOIpEJF7HsAmOo 7JbDwvoOPClQKpw72KnJr9nUmWEh8bJ4l+05SNyIWdbIQwPOhIWnSyzOPjAbNylxnrEL mUthpxeEmeuE7FWQLn2eVEPdAaLu5BTfN3hYBhnaRBAErgceS8JLZ4VAPD3L2iW2PQ13 BjQTCTnPESn0PkTjThMtLKJZtjrWI3cYH76GsuiMRSZfJqPPQPFGbZ7TOorIdpimKq29 XiBm/CktdCocfhzU/2Kl69NC/id0PhiGaXKQul48aNUfNLhecI9PnPBbrnVGbRHLo9m8 qJ2g==
X-Received: by 10.60.94.244 with SMTP id df20mr5242803oeb.16.1428097096076; Fri, 03 Apr 2015 14:38:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.213.206 with HTTP; Fri, 3 Apr 2015 14:37:55 -0700 (PDT)
From: Fabrice Gautier <fabrice.gautier@gmail.com>
Date: Fri, 3 Apr 2015 14:37:55 -0700
Message-ID: <CANOyrg9BSVAtVC4y34jMi-OAbK5OHMFsTUOhxRJqgGKGzO41xQ@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/6uoirQV-b1buZ-rYCWUxxN67X7g>
Subject: [TLS] Interaction between session resumption and negotiated protocol version
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: Fri, 03 Apr 2015 21:38:18 -0000

Hi all,

It's not clear to me what should be the protocol version be selected
when trying to resume sessions.

For the cipher_suite in the ServerHello, the TLS 1.2 RFC explicitly says:

      For resumed sessions, this field is the value from the state of
the session being resumed.

But for the protocol_version it does not say anything specific about
resumption, so, its just:

      This field will contain the lower of that suggested by the
client in the client hello and the highest supported by the server.


I also note that in Section 7, the definition of a Session does NOT
include the protocol version.


Given that, it seems that it's acceptable for a server to attempt to
resume a session with TLS 1.2 that was originally established with TLS
1.0, or vice-versa.

That seems wrong, but I also guess this is a very plausible scenario
given that many implementation do version fallback if something goes
wrong.

So what should be the behavior of a server when trying to resume but
there is a version mismatch ?

(1) Cache the old ClientHello.version and  do not resume a session if
the new ClientHello.version does not match the cached one.
(2) Cache the old ServerHello.version and do not resume if the new
ClientHello.version does not allow to negotiate the same
ServeHello.version. Allow resuming at lower version even if both side
support higher version.
(3) Cache the old ServerHello.version and do not resume unless the
cached version is the max of ClientHello.version and max supported
Server version. (e.g.: Do full handshake at best version instead of
downgrading to a lower cached version)
(4) Don't cache any version, always attempt to resume with the max of
ClientHello.version and max supported Server version


My guts tell me that (3) is the right thing to do.

What do other think ?


Thanks

-- Fabrice