Re: [TLS] Unifying tickets and sessions

Hubert Kario <hkario@redhat.com> Thu, 23 October 2014 14:31 UTC

Return-Path: <hkario@redhat.com>
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 98D401A9234 for <tls@ietfa.amsl.com>; Thu, 23 Oct 2014 07:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rlE6p5shKI2w for <tls@ietfa.amsl.com>; Thu, 23 Oct 2014 07:31:35 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFED1A9023 for <tls@ietf.org>; Thu, 23 Oct 2014 07:31:34 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NDmo3Q031132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 23 Oct 2014 09:48:50 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-150.brq.redhat.com [10.34.0.150]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9NDmmeU026583 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2014 09:48:50 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Thu, 23 Oct 2014 15:48:47 +0200
Message-ID: <1956811.gQP5ABpcIW@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <20141022190937.GI19158@mournblade.imrryr.org>
References: <CAO7N=i38zutXpmuMKuv1CHrc3hO-zm6U+nsGgE6NF4YmC54tDQ@mail.gmail.com> <5447FA87.40007@fussenegger.info> <20141022190937.GI19158@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6EdvDE5owDJkH7oxHaZfS5tqT3k
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: Thu, 23 Oct 2014 14:31:41 -0000

On Wednesday 22 October 2014 19:09:37 Viktor Dukhovni wrote:
> 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:
> 
<snip>
> 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.

I'd really like to see such code in OpenSSL. It would certainly help to make 
sure that the TLS 1.3 implementation meets the goals of TLS 1.3 charter.

-- 
Regards,
Hubert Kario