IETF Logo Mail Archive

Re: [TLS] Security review of TLS1.3 0-RTT

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 03 May 2017 15:58 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10671129B19 for <tls@ietfa.amsl.com>; Wed, 3 May 2017 08:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham autolearn_force=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 Fd4wNizH4smt for <tls@ietfa.amsl.com>; Wed, 3 May 2017 08:57:59 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF161129435 for <tls@ietf.org>; Wed, 3 May 2017 08:55:47 -0700 (PDT)
Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 644CB7A32F1 for <tls@ietf.org>; Wed, 3 May 2017 15:55:46 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAAF6GDdpq8DgLx5Fo6apoTHgwQsbdn6hb=ozi1+JP9VMxPw6sA@mail.gmail.com>
Date: Wed, 03 May 2017 11:55:45 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org>
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com> <cb518e35-c214-d11d-a068-c454b2e7ea6a@gmx.net> <CAAF6GDfQ+YXV4gvhBOOZKC=wtYhxQUy1_2_M+dgfbdL25pppiQ@mail.gmail.com> <BCD73E79-0675-4B71-92B4-3226F0BAB597@dukhovni.org> <CAAF6GDdpq8DgLx5Fo6apoTHgwQsbdn6hb=ozi1+JP9VMxPw6sA@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GmHJwlsXKHlfNLzIKo5UXqs8qYg>
Subject: Re: [TLS] Security review of TLS1.3 0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 03 May 2017 15:58:01 -0000

> On May 3, 2017, at 11:22 AM, Colm MacCárthaigh <colm@allcosts.net> wrote:
> 
> There's nothing enforcing that, and research has shown STEKs being used for long periods of time.

That's an implementation defect.  Not a problem with STEKs as such.

In Postfix STEK lifetime == 2 * session lifetime (the latter defaults to 1 hour).

Some time this year I'll introduce key rotation by default into OpenSSL, which
will result in short-term STEKs for all applications that don't implement session
ticket key management callbacks.  That way, it is not just applications that take
the time to handle key rotation that will get short-term STEKs. 

Mind you, long-lived servers such as Apache, Nginx, ... should also implement
key rotation via the relevant callback mechanisms and should not use static
keys.  Sloppy implementations are not a problem with STEKs, the same sloppy
implementations will just as likely have insecure caches.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email