IETF Logo Mail Archive

Re: [TLS] Unifying tickets and sessions

Manuel Pégourié-Gonnard <mpg@polarssl.org> Mon, 20 October 2014 21:39 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 CA5A91ACF07 for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 14:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.997
X-Spam-Level:
X-Spam-Status: No, score=0.997 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, J_CHICKENPOX_32=0.6, 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 I_xXn3O8P-YX for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 14:39:37 -0700 (PDT)
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 DE5851ACF04 for <tls@ietf.org>; Mon, 20 Oct 2014 14:39:36 -0700 (PDT)
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:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=v3qHk4GAOJW4M4yyn5dZW9ZN/lS5dgVZE9D9tgmVEKM=; b=C9MGxAXzK8ErnD+V6yC8kn8aWDA/R5xZIPezQYyHGflJ4fApdHmVyDtDTCWIwRPSulriU+6vBgi67Gqv/V44HcYlOSpIyrnEdUC2vJRbZrX2ifHhDX4+gpuFpaf2+Hf/wVS5UFplg953fDnXo/PjOx6g70K3au0c0vOi+QDsn6o=;
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 1XgKfn-0004DA-Vk; Mon, 20 Oct 2014 23:39:28 +0200
Message-ID: <54458113.1050304@polarssl.org>
Date: Mon, 20 Oct 2014 23:39:31 +0200
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: "Richard Fussenegger, BSc" <richard@fussenegger.info>, "Salz, Rich" <rsalz@akamai.com>, "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info>
In-Reply-To: <5445775E.3050108@fussenegger.info>
Content-Type: text/plain; charset="windows-1252"
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/kUGK8h08LEpuuN1j9z-6tbpCF6s
Subject: Re: [TLS] Unifying tickets and sessions
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, 20 Oct 2014 21:39:39 -0000

On 20/10/2014 22:58, Richard Fussenegger, BSc wrote:
> Nice to see this merge and I directly +1 the token wording.
> 
++

> The RFC should clarify that the negotiated cipher **MUST** be honored 
> when encrypting the state that will be sent to the client. [1]
> 
While I'm sympathetic with the goal, I'm afraid that will complicate
implementations more than necessary. How about requiring to use a key length at
least a high as the highest supported ciphersuite instead?

One concern is that it's generally not recommended to use the same key with
different ciphers, so implementations would need to derive a key for each cipher
from a master key. That's certainly doable, but it adds a bit of complexity.

Another point is that we need to be sure that the same ciphersuite be selected
on resumption than on the original handshake. Since some extensions are needed
to choose the ciphersuite (at least SNI, signature_algorithms, the EC
extensions), it means those extensions need to be parsed before picking the
ciphersuite but the session_ticket extension after picking it. Nothing
insurmountable obviously, but again, complexity.

(Thinking while writing.) Perhaps more importantly, if a ciphersuite becomes
weak enough, an attacker could create tickets by forcing the server to
decrypt/authenticate them with the least secure ciphersuite it's willing to
accept, and use that to bypass client auth and.or mount other kind of attacks in
the server.

I'm not so sure the last paragraph is a real threat, but if it is, then it's
probably much safer to pick a single trusted cipher (or AEAD-cipher) and
conservative key size (such as 256 bits) for all tickets: of course it creates
an upper bound on the security of all sessions, but also a lower bound on ticket
authentication.

Manuel.

v2.23.0 | Report a Bug | By Email