IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 03 May 2017 23:26 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 636A5127873 for <tls@ietfa.amsl.com>; Wed, 3 May 2017 16:26:27 -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 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 7jCMN0xDWeBN for <tls@ietfa.amsl.com>; Wed, 3 May 2017 16:26:26 -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 CB21D12778E for <tls@ietf.org>; Wed, 3 May 2017 16:26:25 -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 D41557A32F1 for <tls@ietf.org>; Wed, 3 May 2017 23:26:24 +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: <CAAF6GDf-aJEu8Usss7r9m94YXSVgHq8OB9+=i8-uk=Cv_QtrwA@mail.gmail.com>
Date: Wed, 03 May 2017 19:26:23 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <8EF519E7-BD1E-4449-A1DF-F89CD3C68760@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> <539D071B-7DDD-4820-A9E4-EC178400B7B2@dukhovni.org> <420471d6016a41ecbcdf9562be303f62@ustx2ex-dag1mb1.msg.corp.akamai.com> <17414FC2-15BB-4A03-8673-7F8299E5428E@dukhovni.org> <20170503182955.GR10188@localhost> <CAAF6GDf_5tuU=L8vCv5f1wgwy8NxvDcJb9TjJ+iHcNOqETASoQ@mail.gmail.com> <7573B494-A1C1-4897-B064-14237B5FB525@dukhovni.org> <CAAF6GDfiLtLT5-NZwFaSHmz35MRiNSqSjQt=MmNoQ04vBDPPTg@mail.gmail.com> <658E74AE-39BC-4518-B11D-92D7AC7F1BD4@dukhovni.org> <CAAF6GDf-aJEu8Usss7r9m94YXSVgHq8OB9+=i8-uk=Cv_QtrwA@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/W7BXuPsxMhaVhsFfc8M_ct-BzqQ>
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 23:26:27 -0000

> On May 3, 2017, at 6:29 PM, Colm MacCárthaigh <colm@allcosts.net> wrote:
> 
> Just an aside related to that; it can be useful to fuzz ticket lifetimes a
> bit so all of the tickets from a STEK don't expire at exactly the same time.
> That can lead to a lot of painful renegotiations happening at once.

More than "a bit".  In Postfix session tickets have a constant lifetime regardless
of whether they were issued at the beginning of end of the current STEKs duration
is the STEK encryption key.  This works, because each STEK is retained as a
decryption-only key for a second "lifetime" while the next key is employed to
encrypt (and decrypt) new sessions.

There is no clustering of session expirations.  The plan is to do the same in
the default-on key rotation for OpenSSL.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email