IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 02 May 2017 18:54 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 B6CB412E053 for <tls@ietfa.amsl.com>; Tue, 2 May 2017 11:54:51 -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 8EYtyJ1bfTyj for <tls@ietfa.amsl.com>; Tue, 2 May 2017 11:54:50 -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 BBA3812947A for <tls@ietf.org>; Tue, 2 May 2017 11:51:07 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (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 0D4BD7A32F1 for <tls@ietf.org>; Tue, 2 May 2017 18:51:07 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <d325ae84-ad24-859d-50a7-825dbabe3b24@akamai.com>
Date: Tue, 02 May 2017 14:51:06 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <39C55E05-183F-415D-8E99-1798DD2303D8@dukhovni.org>
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com> <C29356B3-6D71-4088-9AB3-4954327F1E7B@dukhovni.org> <20170502173905.GC10188@localhost> <CAAF6GDeYc5o=eeeyV6HhK9vrLngB-Y=Ed5BdedrE8h2-py4oAw@mail.gmail.com> <20170502180049.GE10188@localhost> <CAAF6GDecd=x-Ob_eO1vSWr6cb6jAeyHBx7zf6cpX=GfxBosfLQ@mail.gmail.com> <20170502182529.GG10188@localhost> <d325ae84-ad24-859d-50a7-825dbabe3b24@akamai.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gEiHiNZxi5xlXrpcHbJydHtDGnQ>
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: Tue, 02 May 2017 18:54:52 -0000

> On May 2, 2017, at 2:39 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
> 
> I thought TLS clients were supposed to have even worse clocks (in terms of absolute time) than Kerberos clients.  The current ticket_age scheme only requires the client's clock *rate* to be reasonable, not its absolute time.

Sure, and yet it might still have been better to transport the "obfuscated ticket age"
as an "encrypted ticket age", while keeping the elements of the design that expect only
a reasonable clock rate from the client.  Of course making such a change is likely
prohibitive at this time...

If the ticket is never re-used the "obfuscation" is perhaps sufficient, and if it
is re-used both obfuscation and encryption are defeated.  So obfuscation is perhaps
acceptable.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email