[TLS] RFC 7366 and resumption

Manuel Pégourié-Gonnard <mpg@polarssl.org> Wed, 05 November 2014 14:44 UTC

Return-Path: <mpg@polarssl.org>
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 3C0831A896D for <tls@ietfa.amsl.com>; Wed, 5 Nov 2014 06:44:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level:
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 Lxx3jL8vhBV5 for <tls@ietfa.amsl.com>; Wed, 5 Nov 2014 06:44:49 -0800 (PST)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2587D1A894A for <tls@ietf.org>; Wed, 5 Nov 2014 06:44:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:To:MIME-Version:From:Date:Message-ID; bh=d5ZXZo/asyFrUivydWVEfEjk8h4ixkj5ozwe7iFNh1k=; b=noYy6Gz3KeCs+E1AleyJFzyAMMfy0htcHRVEjfJfzPc0y28FlMsdgL4Hz6V17tF3KISpLuqXfA1AzSdupTXp7Ksm0A8bJ4H+2N4+Pv3YpTwrh4OaA4RByS/5GliMtzWfBd6IvwkE3RgKn1vff09eqOjI3iFMaitsZrSXvXbC2zw=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1Xm1pB-0003yt-3m for tls@ietf.org; Wed, 05 Nov 2014 15:44:41 +0100
Message-ID: <545A37DE.6000501@polarssl.org>
Date: Wed, 05 Nov 2014 15:44:46 +0100
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5NtqVpTsmmic_eo6x7CBzDACBLA
Subject: [TLS] RFC 7366 and resumption
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: Wed, 05 Nov 2014 14:44:50 -0000

Hi,

Unless I missed it, RFC 7366 does not say what should happen during
session resumption. So I checked what RFC 5246 has to say:

   In general, the specification of each extension type needs to
   describe the effect of the extension both during full handshake and
   session resumption.  Most current TLS extensions are relevant only
   when a session is initiated: when an older session is resumed, the
   server does not process these extensions in Client Hello, and does
   not include them in Server Hello.  However, some extensions may
   specify different behavior during session resumption.

It seems to me that RFC 7366 falls in the same category as "Most current
TLS extensions" above, ie is only relevant when a session is initiated,
and on resumption the server should ignore the extension and restore the
state from the saved session.

Eg: (Assuming a CBC ciphersuite is used.)
Initial handshake: client sends EtM ext,
                   server replies with EtM ext,
                   EtM is used to protect traffic.
Resumed handshake: client sends EtM ext + ticket/session ID,
                   server chooses to resume session,
                   server does not send back the EtM extension,
                   EtM is used to protect traffic.

For example, this is what RFC 6066 prescribes for the truncated_hmac
extension that is very similar in the way it works (except it lowers
security, while EtM strengthens it...), so it seems only logical to do
the same here.

But I thought it might not hurt to check, just to be sure.

Thanks in advance for any comment,
Manuel.