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

Dave Garrett <davemgarrett@gmail.com> Tue, 30 May 2017 22:32 UTC

Return-Path: <davemgarrett@gmail.com>
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 ECD7C129473 for <tls@ietfa.amsl.com>; Tue, 30 May 2017 15:32:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 vr6SYWdYdY7r for <tls@ietfa.amsl.com>; Tue, 30 May 2017 15:32:26 -0700 (PDT)
Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D6A12946B for <tls@ietf.org>; Tue, 30 May 2017 15:32:26 -0700 (PDT)
Received: by mail-qt0-x244.google.com with SMTP id l39so14133393qtb.1 for <tls@ietf.org>; Tue, 30 May 2017 15:32:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=dj3a8qiIOQPZ0anTsBzFog7ywdLykFnE6Gw6Rgser9o=; b=BjTnfVItesEo+YBqTz1vSFZxWA3pzu9C3k6zwee2Uc9FxwtAXBi5yMH1GzJfCvIotH 8mZBz8NrAfg9kD79IxjlDuUFyS37zJ0tFNAHIsknitRAyYxoQrzi0WjkIqIzE/ap+YsL 8gDTlxkF0Rs0qfsGgEWn/Qr3JsPvqbg/BLP/HN/Y/60NxTdy7eP7rIyY4hUXbUxUN1DM 1JrTA1ijne+kzzTm3Vy+7d702JTrnC2eaFPZpBr3VE9n5QHTjbYJ7PwHKdcL+eT1AiYW NwSca4eIOie5nke1u9TuW9zBA/04h0/66udfzy85mZ1QdKBWXyud8NHshNDki3JXibXh 1yJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=dj3a8qiIOQPZ0anTsBzFog7ywdLykFnE6Gw6Rgser9o=; b=G+vr69v/TLu2O/f/8ZGShIFmkKsiuNet00TVPRnWw+Fdf+jZq09Jdo5UgZVB0H9R6q enY7H1M7xDRAfsi+0uhpn37OJKrGHlfXLQLuqKe4wCbTxhoo3tXMxerU+QFVn6klyORG TiwE/9AsHfdLee7BHXtLOu+HlcyNTFdzW80Wz8u6tglFRBrEa7MwwNlc/5VlExKWti6i r4uHhvT3Torktttcc8RXOcoE/rCtsbG+Fk3hEqccZtwbCgki/BqNcTQ1Uy2Yp2M4ejXz 8PTulICPZjp2SxoqRk15L1SaIXUk7gruvxvgQ64jKC0O5Xhf4tinL1Uv0ElKDwk1mfq4 7JoQ==
X-Gm-Message-State: AODbwcCmuj5LkvV+XVe/h5pijjQ+3fN2aJRjmNHfwUcYoU4YQBAoluvt TJlnqu1ZXcRZifcs
X-Received: by 10.200.3.195 with SMTP id z3mr28254329qtg.185.1496183545500; Tue, 30 May 2017 15:32:25 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-36-114.phlapa.fios.verizon.net. [71.185.36.114]) by smtp.gmail.com with ESMTPSA id u19sm9230371qtc.64.2017.05.30.15.32.24 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 30 May 2017 15:32:24 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Tue, 30 May 2017 18:32:22 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com> <CAAZdMacpJ-qoQt2pDBjTq6ADwmRKOHXTHDyDTzb+g2gYPvtZzQ@mail.gmail.com>
In-Reply-To: <CAAZdMacpJ-qoQt2pDBjTq6ADwmRKOHXTHDyDTzb+g2gYPvtZzQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201705301832.23150.davemgarrett@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KGRbdaKIW7wAJoI_0mxjCx4zAbc>
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, 30 May 2017 22:32:28 -0000

On Tuesday, May 30, 2017 05:38:02 pm Victor Vasiliev wrote:
> TLS isn’t a magical “transport security solution”, it provides a very specific
> set of explicit security guarantees to the applications that use it.  It can be
> used as a building block for the secure systems, but at the end of the day, the
> security of a system hinges on the designers’ understanding of the security
> contracts provided by individual components.
> 
> TLS 1.3 as-is does not remove any of the replay protection guarantees provided
> by TLS 1.2.  However, if the user chooses to waive said protection in order to
> do 0-RTT, they can do that with an API explicitly designed for that purpose.

+1; In fact, I'd suggest sticking this almost as-is into the spec somewhere.

>   C. “Nebulous” replay bound.  0-RTT data can be replayed, but only for some
>       finitely bounded number of times.  I initially wanted to call this “weak
>       replay protection”, but that felt too generous.
> 
> Normally I would dismiss this as a useful security property due to its inherent
> vagueness, for the same reasons that “your server is too far away for
> nanosecond-level timing attacks on Intel CPUs” is a property that no serious
> cryptographer would admit in a research paper.  However, you’ve pointed out some
> interesting side channel leaks, which exist even without 0-RTT, but can be
> amplified by replaying 0-RTT queries. C, like B, mitigates this, so this is a
> meaningful property to provide.
> 
> Let’s talk about what mechanisms are and are not viable for the nebulous
> bound promise.

There is one relatively straightforward mechanism for limiting 3rd party replay:
A 3rd party replaying 0-RTT PSK will fail to successfully complete the handshake
(after 1-RTT), as it would generally have the identity/ticket but not the key
behind it (e.g. resumption_master_secret). The 0-RTT data will have already been
processed, however a server detecting any PSK failure could then flag the
offending ticket/IP and reject all future 0-RTT attempts for some time period (e.g.
ticket lifetime). This would limit replays to one per server, or less if this banned
0-RTT state is shared across servers. The notable problem with this mechanism
is that a 0-RTT DDoS, could easily balloon the state size rather significantly, if not
careful. Servers would have to be fine with budgeting resources for a nontrivial
state in the event of attack, even if they don't need it during normal operation,
but that could at least be doable. A replay from the 1st party that is expected to
have the correct key/secret or from a 3rd party that has stolen it would not be
mitigated by this system, but that's much harder for an attacker to attempt, at
least.


Dave