Re: [TLS] Closing on 0-RTT

Joseph Salowey <joe@salowey.net> Fri, 23 June 2017 16:22 UTC

Return-Path: <joe@salowey.net>
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 60E351200B9 for <tls@ietfa.amsl.com>; Fri, 23 Jun 2017 09:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 purwPnxlwKh5 for <tls@ietfa.amsl.com>; Fri, 23 Jun 2017 09:22:04 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 691141289B0 for <tls@ietf.org>; Fri, 23 Jun 2017 09:22:03 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id q86so25542748pfl.3 for <tls@ietf.org>; Fri, 23 Jun 2017 09:22:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ezwHF5/ywrEGyQyNj85pPZchYATSV7BllqlCaEZ2E2c=; b=IMSRVy6ytfO1kCfmdoQAMYR9EUW3HRESMtECRG6so/78D0CHJ2WY7QvL3hEk3RXb7I SVNt1u8BAQf1peQQFZzy6xlt89PZvyKssnEfEGQ9Zy+NLKxStniW13DefEXuVsmKCN9G gdiNtQbCccz5yGl4IHpScqa9Wtzau/3htkQCZF2QeZfpO+B5lHd/yz4fceVFMA5o44LH Lcd3Muxlq1omW82KXZbDf2kbbS1JtbYsV1UKhxTDX3iUJK8xtrT1QZDC7MvdBCc7sdsW nRikPz9AWpHRExRC4puxKfYPby+W1GDA1slcG30uztfnZsq7Icb09JWo1FBzunh7FG6g kakQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ezwHF5/ywrEGyQyNj85pPZchYATSV7BllqlCaEZ2E2c=; b=TeSXTr1LEIBS82uoOrQt7KQIE441DRVaBYfw4k+LzGYuuy9MhRCpRZslakraunGZwp 8HvOa6brHng/RcTCId+4suPERyGuAYuv9Vgoe/EzFYJqvoh/MrKhzi2f2UZZnX8+xHiw Hvib3NZkB8IHUqidz5EZwZMR028Ms4iF52zC9V0EnySj+IMdRDiTXhFKha1gtFYdDdeC 21lefDG7gZpo/UNbf22JDb8LqWVDc+/bL6evmwLdAynL+FG1C7Vw4M2h0iTJs/6IfEgn Oos4qg8V8cSPfYxs29aN7Gy0dEtfVJ/wNU3F2ktx3uBXY43P5F0RNSUzghICbR29TYAc +vCg==
X-Gm-Message-State: AKS2vOzIsLeIbznizqCPfzwPH6upAQyTHnHT9AaSwQjXi2K5osfhMR1v aPjwrA1YsQCn0H0FeQDFGhdU4gY2noxR
X-Received: by 10.98.141.134 with SMTP id p6mr9122538pfk.68.1498234923004; Fri, 23 Jun 2017 09:22:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.176.233 with HTTP; Fri, 23 Jun 2017 09:21:42 -0700 (PDT)
In-Reply-To: <20170614174531.GA17930@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> <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> <CAH9QtQFez=tUVJOd7ztBaWFtVs5dAAojg8JrixGqjwqN5go+8A@mail.gmail.com> <20170614174531.GA17930@LK-Perkele-V2.elisa-laajakaista.fi>
From: Joseph Salowey <joe@salowey.net>
Date: Fri, 23 Jun 2017 09:21:42 -0700
Message-ID: <CAOgPGoAmo1p9BwfxyeA=iWbOpVtbxJsVpdN0TzVuV=bVyFiWEA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0ecffa6055c70552a30011"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YVSWIRmb8eov5uDpeq5ebP--ZmI>
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: Fri, 23 Jun 2017 16:22:07 -0000

Hi Ekr,

Discussion on this topic is dying down, can you post a PR so we can see the
proposed text.  There is still some discussion on the API thread so there
may be some additional modifications coming in that area.


On Wed, Jun 14, 2017 at 10:45 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Tue, Jun 13, 2017 at 03:24:24PM -0700, Bill Cox wrote:
> > On Tue, Jun 13, 2017 at 1:51 PM, Ilari Liusvaara <
> ilariliusvaara@welho.com>
> > wrote:
> >
> > > >   - 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.
> > >
> >
> > I assumed "gobal anti-replay" meant there would be a globally
> synchronized
> > cache of valid single-use tickets.  It sounds like you mean "global
> > anti-replay" includes schemes using orbit/metro/server bound tickets,
> since
> > they can support single-use tickets.  In that case, I agree with you,
> but I
> > think the phrase "single-use tickets" may be less confusing.  Maybe just
> > say "anti-replay" instead of "global anti-replay"?
>
> IMO, "anti-replay" also includes per-server anti-replay, which archives
> "at most N replays" in global scale.
>
> Of course, the ticket scope of server can be wider than the 0-RTT scope
> (the server accepts tickets but rejects 0-RTT from any ticket in
> between).
>
> > 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.
> > >
> >
> > I don't know what you mean by "resulting the same exporter output."  Auth
> > signatures in a 1-RTT fallback need to be recomputed using the 1-RTT
> > exporter to avoid having the same signature accepted twice.  Maybe this
> is
> > too specific and should be left out.
>
> If you replay ClientHello and it gets accepted twice, including to
> different servers, both connections have the same 0-RTT exporter values.
>
> The 1-RTT exporter values will not be the same, but this is not helpful
> for 0-RTT data, or for that matter any 1-RTT data unless exporters are
> switched mid-stream.
>
> > > 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.
> > >
> >
> > It depends on the task.  Moving channel ID from the TLS layer to token
> > binding in the HTTP layer should simplify the TLS state machine enough to
> > justify the change.
>
> Implementing such thing without some TLS support at application layer is
> just crazy.
>
> IMO, the only reason token binding concerns itself at all with TLS is
> that "0.5 RTT" (a TLS 1.3 feature) and HTTP/2 was not available when
> token binding was started. Those (together with exporters) would have
> enabled token binding in HTTPS without having to mess with TLS.
>
> (The messing with TLS in token binding seems to be solely about saving
> round-trips!)
>
> > Anti-replay in the TLS layer would be good for 0-RTT
> > token binding, but the cost and complexity of running the whole
> user-facing
> > fleet of servers with anti-replay caches is huge, many times higher than
> > the cost of token-binding anti-replay in the backend.  Also, the
> > authentication backend is where bound tokens are currently verified, so
> > putting the anti-replay there seems like the appropriate layer.
>
> That greatly depends on the implementation and deployment. That's why it
> is more fragile.
>
> E.g. run more than one authentication backend for 0-RTT scope, and
> your application layer anti-replay breaks. And I'm not convinced the
> scale of anti-replay cache would be much smaller at application layer, in
> fact, it could be even biger.
>
> > I'm still not sure this scheme is worth implementing, but without it, I
> do
> > not think we can support client certificates or token binding over 0-RTT.
> > It doesn't really matter for the TLS 1.3 spec.  I'm just pointing out
> that
> > the statement "0-RTT auth is insecure without anti-replay defense" is not
> > 100% accurate.  There are other ways to improve the security.
>
> Well, client certificates are currently forbidden for connections with
> 0-RTT data (indirectly, but it is still forbidden). It could become
> possible
> in the future.
>
>
>
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>