Re: [TLS] Unifying tickets and sessions

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 23 October 2014 20:07 UTC

Return-Path: <ietf-dane@dukhovni.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 455CB1ACEAD for <tls@ietfa.amsl.com>; Thu, 23 Oct 2014 13:07:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ko1qP5fp8-iM for <tls@ietfa.amsl.com>; Thu, 23 Oct 2014 13:07:04 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2E31A0861 for <tls@ietf.org>; Thu, 23 Oct 2014 13:07:04 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9F4592AB2B5; Thu, 23 Oct 2014 20:07:02 +0000 (UTC)
Date: Thu, 23 Oct 2014 20:07:02 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20141023200702.GZ19158@mournblade.imrryr.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <CAK3OfOj9bZcSDdWhHGeGT0STg6XBkYaExW+rQFN-FFE4oaPLrw@mail.gmail.com> <54483C33.4000702@polarssl.org> <11886639.VyNDkQ3oKj@pintsize.usersys.redhat.com> <54493904.7010807@fussenegger.info> <20141023174537.GW19158@mournblade.imrryr.org> <5449463D.7080904@fussenegger.info> <20141023183637.GX19158@mournblade.imrryr.org> <54494F20.7060002@fussenegger.info>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <54494F20.7060002@fussenegger.info>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F2DzTe8Hi2qBt2ZpI0q2H8h4LIw
Subject: Re: [TLS] Unifying tickets and sessions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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: Thu, 23 Oct 2014 20:07:06 -0000

On Thu, Oct 23, 2014 at 08:55:28PM +0200, Richard Fussenegger wrote:

> On 10/23/2014 8:36 PM, Viktor Dukhovni wrote:
> >The iv should not be part of the persistent key set.  It is a new
> >random value for each client, returned to the server as part of
> >the ticket.  The key set is just (name, key, mac).  The in memory
> >version in Postfix also holds a timeout:
> >
> >     typedef struct TLS_TICKET_KEY {
> >	unsigned char name[TLS_TICKET_NAMELEN];
> >	unsigned char bits[TLS_TICKET_KEYLEN];
> >	unsigned char hmac[TLS_TICKET_MACLEN];
> >	time_t  tout;
> >     } TLS_TICKET_KEY;
> 
> I didn't implement it but nginx requires 48 B otherwise it's not working and
> that's definitely more than only key and mac. Maybe the complete thing is
> broken in nginx then? [1]

The reason nginx has 48 bytes is that it stores a 16 byte name,
followed by a 16-byte (AES-128) key and a 16-byte HMAC secret.

Postfix uses 16 + 32 + 32 = 80, because the key is for AES-256 and
the HMAC key for SHA2-256 is also chosen to be 256 bits.

The nginx implementation can be "strengthened" from AES-128 to
AES-256 just in case someone wants to burn a few million years of
a 4GW power plant to brute force a session ticket on a classical
computer, or future quantum computers can search a 2^128 key space
in 2^64 time.

-- 
	Viktor.