Re: [TLS] Unifying tickets and sessions

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 22 October 2014 19:10 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 564931ACFFC for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 12:10:33 -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=unavailable
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 cP0lbWn3ohcT for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 12:10:21 -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 CE4891AD006 for <tls@ietf.org>; Wed, 22 Oct 2014 12:09:39 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CD3E52AB04A; Wed, 22 Oct 2014 19:09:37 +0000 (UTC)
Date: Wed, 22 Oct 2014 19:09:37 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20141022190937.GI19158@mournblade.imrryr.org>
References: <CAO7N=i38zutXpmuMKuv1CHrc3hO-zm6U+nsGgE6NF4YmC54tDQ@mail.gmail.com> <5447FA87.40007@fussenegger.info>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5447FA87.40007@fussenegger.info>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6tk4sc-1DGPf1RS2H19YX2EkYIk
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: Wed, 22 Oct 2014 19:10:33 -0000

On Wed, Oct 22, 2014 at 08:42:15PM +0200, Richard Fussenegger wrote:

> Viktor Dukhovni already mentioned that
> OpenSSL is actually supporting different key strengths, but for instance
> nginx isn't exposing this setting to administrators.

For the record OpenSSL makes it possible for applications to use
some other block cipher than aes-128-cbc, but this is not as easy
as it sounds.  The application needs to register appropriate
callbacks and take over key life-cycle management.  So simply using
some other cipher-suite is not a trivial exercise, rather only once
one is already managing key rotation via the callbacks, making the
cipher configurable is trivial:

The code for this is roughly:

    #define TLS_TICKET_NAMELEN      16      /* RFC 5077 ticket key name length */
    #define TLS_TICKET_IVLEN        16      /* RFC 5077 ticket IV length */
    #define TLS_TICKET_KEYLEN       32      /* AES-256-CBC key size */
    #define TLS_TICKET_MACLEN       32      /* RFC 5077 HMAC key size */

    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;

    #define NOENGINE				((ENGINE *) 0)
    #define TLS_TKT_NOKEYS	-1		/* No keys for encryption */
    #define TLS_TKT_STALE	0		/* No matching keys for decryption */
    #define TLS_TKT_ACCEPT	1		/* Ticket decryptable and re-usable */
    #define TLS_TKT_REISSUE	2		/* Ticket decryptable, not re-usable */

    static int ticket_cb(SSL *con, unsigned char name[], unsigned char iv[],
			      EVP_CIPHER_CTX * ctx, HMAC_CTX * hctx, int create)
    {
	static const EVP_MD *sha256;
	static const EVP_CIPHER *ciph;
	TLS_TICKET_KEY *key;
	int     timeout = ((int) SSL_CTX_get_timeout(SSL_get_SSL_CTX(con))) / 2;

	if ((!sha256 && (sha256 = EVP_sha256()) == 0)
	    || (!ciph && (ciph = EVP_get_cipherbyname(var_tls_tkt_cipher)) == 0)
	    || (key = tls_mgr_key(create ? 0 : name, timeout)) == 0
	    || (create && RAND_bytes(iv, TLS_TICKET_IVLEN) <= 0))
	    return (create ? TLS_TKT_NOKEYS : TLS_TKT_STALE);

	HMAC_Init_ex(hctx, key->hmac, TLS_TICKET_MACLEN, sha256, NOENGINE);

	if (create) {
	    EVP_EncryptInit_ex(ctx, ciph, NOENGINE, key->bits, iv);
	    memcpy((char *) name, (char *) key->name, TLS_TICKET_NAMELEN);
	} else {
	    EVP_DecryptInit_ex(ctx, ciph, NOENGINE, key->bits, iv);
	}
	return (TLS_TKT_ACCEPT);
    }

Plus additional supporting functions to fetch encryption/decryption
keys, subject to appopriate key rotation policies, (in the above
case tls_mgr_key() whose implementation is rather application
specific).

Perhaps I'll donate a variant of this code to OpenSSL, and then we
can ask users to just provide algorithm name, and either a key
lifetime for automatic in memory keys or callbacks to access
externally managed keys.

-- 
	Viktor.