Re: [TLS] Closing on 0-RTT

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 13 June 2017 20:51 UTC

Return-Path: <ilariliusvaara@welho.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 9AD561200C5 for <tls@ietfa.amsl.com>; Tue, 13 Jun 2017 13:51:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 LToMu4krvtaJ for <tls@ietfa.amsl.com>; Tue, 13 Jun 2017 13:51:20 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 33500126E3A for <tls@ietf.org>; Tue, 13 Jun 2017 13:51:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id A89E06366C; Tue, 13 Jun 2017 23:51:18 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id aiXgksPC227f; Tue, 13 Jun 2017 23:51:18 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 213D8288; Tue, 13 Jun 2017 23:51:18 +0300 (EEST)
Date: Tue, 13 Jun 2017 23:51:13 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Bill Cox <waywardgeek@google.com>
Cc: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBNLo51y4-MYS6NTQn9OWg5jTYYpwxn1fiKKNL5bWA37TA@mail.gmail.com> <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> <CAH9QtQG0uk+eUozJxxMRwvcROO7x5FhKd5zDbwpCKuXj9zrecQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAH9QtQG0uk+eUozJxxMRwvcROO7x5FhKd5zDbwpCKuXj9zrecQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GXFfyzqyJhsUH38OaQ3HqSafQR0>
Subject: Re: [TLS] Closing on 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, 13 Jun 2017 20:51:23 -0000

On Tue, Jun 13, 2017 at 12:06:26PM -0700, Bill Cox wrote:
> On Tue, Jun 13, 2017 at 4:32 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> 
> > Also:
> >
> > - Note that 0-RTT exporters are not safe for authentication unless
> >   the server does global anti-replay on 0-RTT.
> 
> 
> I do not think this is the case.  Nick Harper has proposed an RFC for token
> binding over 0-RTT:
> 

>   - Note that 0-RTT exporters are not safe for authentication on servers
> that do not enforce single-use tickets, or for clients that do not
> recompute authentication signatures on retransmission of early data.

"Single-use tickets" imply global anti-replay.

And the latter part is way too obscure. I have no idea how it is
trying to fix ClientHello replay resulting the same exporter
output.

E.g., for Triple Handshake, one can mitigate the vulernability for
using the exporter outputs for authentication, but the EMS spec does
not document the methods of doing this for good reasons.

> Even this is only partially true.  Anti-replay can be built above the TLS
> layer.  I'm considering doing token-binding replay defense in the
> authentication backend, to help ensure the token-binding guarantee: that
> auth tokens taken from one device cannot be used from another device
> without continued access to the first device's signing oracle.
> Unfortunately, 0-RTT master resumption secrets are a new kind of auth
> bearer token, and the token binding spec does not cover them.

Doing stuff like this gets more and more complicated and fragile as
one moves up the layer stack.


-Ilari