[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.
- Re: [TLS] RFC 7366 and resumption Martin Rex
- [TLS] RFC 7366 and resumption Manuel Pégourié-Gonnard
- Re: [TLS] RFC 7366 and resumption Peter Gutmann
- Re: [TLS] RFC 7366 and resumption Manuel Pégourié-Gonnard
- Re: [TLS] RFC 7366 and resumption Manuel Pégourié-Gonnard