IETF Logo Mail Archive

Re: [TLS] Unifying tickets and sessions

Manuel Pégourié-Gonnard <mpg@polarssl.org> Wed, 22 October 2014 23:22 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 3608C1AD40F for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 16:22:34 -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_15=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 oeDmn-VIimgt for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 16:22:33 -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 9DE8D1A87C8 for <tls@ietf.org>; Wed, 22 Oct 2014 16:22:32 -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=tsaPqgYOJEg95g4oVgN6/J8Y/UCTKw61WZS271Ce8yo=; b=FSkz+Rp0tX1El+l1/R3zs6lQhrvMG0xrsQRBSarxsZi+TTZ8l9zCVqUlu50OlTsw63pCmw3AwBR6jnnIFjxgAaC0B8wfVvp89cLJWOWugxQL2vNj/a0KWEexgcg+TTMgBWq4V6RFhpoWljxgQ1yBqxiH7ODIpmFrlU+MFxO8MxU=;
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 1Xh5EV-0007u6-CK; Thu, 23 Oct 2014 01:22:26 +0200
Message-ID: <54483C33.4000702@polarssl.org>
Date: Thu, 23 Oct 2014 01:22:27 +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: Nico Williams <nico@cryptonector.com>, "tls@ietf.org" <tls@ietf.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <5445775E.3050108@fussenegger.info> <54458113.1050304@polarssl.org> <20141020235832.GK19158@mournblade.imrryr.org> <CAK3OfOj9bZcSDdWhHGeGT0STg6XBkYaExW+rQFN-FFE4oaPLrw@mail.gmail.com>
In-Reply-To: <CAK3OfOj9bZcSDdWhHGeGT0STg6XBkYaExW+rQFN-FFE4oaPLrw@mail.gmail.com>
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/aYp8RDJa1VoYnoyzGct66-uI7Wg
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: Wed, 22 Oct 2014 23:22:35 -0000

On 22/10/2014 20:46, Nico Williams wrote:
> On Mon, Oct 20, 2014 at 6:58 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>> On Mon, Oct 20, 2014 at 11:39:31PM +0200, Manuel P?gouri?-Gonnard wrote:
>>> 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?
> 
> This is just as silly.  The server should choose what cipher to use, full stop.
> 
I'm afraid you didn't understand what I was actually trying to suggest, but my
sentence was ambiguous: my suggestion was that the server choose what cipher to
use, by looking at what ciphersuites it is prepared to negotiate, and then
picking the most secure symetric cipher from this list (or one of those with
maximal key size).

Eg, if a server is only going to negotiate 128-bit suites because it thinks it's
enough and doesn't want to waste cycles on more than that, then encrypting the
tickets with a 128-bit key is fine. If it is prepared to negotiate 256-bit suite
with some clients, it should encrypt the tickets with a 256-bit key.

Manuel.

v2.23.0 | Report a Bug | By Email