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

Colm MacCárthaigh <colm@allcosts.net> Thu, 01 June 2017 23:59 UTC

Return-Path: <colm@allcosts.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 340E112420B for <tls@ietfa.amsl.com>; Thu, 1 Jun 2017 16:59:15 -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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-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 bNz9uFKvWYfT for <tls@ietfa.amsl.com>; Thu, 1 Jun 2017 16:59:12 -0700 (PDT)
Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 A38E1126CD8 for <tls@ietf.org>; Thu, 1 Jun 2017 16:59:12 -0700 (PDT)
Received: by mail-yb0-x233.google.com with SMTP id 202so14496015ybd.0 for <tls@ietf.org>; Thu, 01 Jun 2017 16:59:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v2surQplLIWoJDcDy4tXoIsDD4yIIqXbkFmwABL4Y34=; b=0zUgfroN5htQnrgDujOT24I2Pg7vhpn/ux+DyGaEL7/fle2riiku1c1mEXEd1MTMX1 E9BaiNVBU0jfhk0hwBY/pEPmjguUYL9Cgkxrq84EcvTTjTAEWqhrFdtkZUy+YS2oDLlX kRdu76PLPfeRXKtrQD/kfS/BwWR0Uiz2aMuK66RM2FclAQHYiGBQjDpdvtAHs/47S15i T6H/+iNcg5c/Ug2Scvm10po2dMIyCg8kDuoLAWp95s95aWXfi8mAohEg81OzlAxaHMBl g8SuzJBKDSTRk6HIIXUTdfVgBxlIdZ/6qBPuNxqvtzrYAINqpTqpQWZAYC3OQF7Wj0L6 Cyrg==
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=v2surQplLIWoJDcDy4tXoIsDD4yIIqXbkFmwABL4Y34=; b=QBW2d7sPDKmp8YZ0Yn60cl+FxtndXFq8rb6ZwoyB7lKp1gan6TImy4chfbojOJvdjI jCQoePQj1raJy9wTXYgaDnuecUiwTab9a7hRzzJu9DGBgkUb6E6p88ul4ab6Sf0f3QF3 0uaua4KhtSMmBuGjksDZkZ9iuuhYeyjLKmGfGOFJR0QYy+A9lg0e3Dd/fdnkzupzLRrw XkbT7dLVdPgJbbE2D3rMXLq3TRdAgjeUS/35SWCQ9tlzKjftufxk79nHjx2WIiJlnoJH qOq4cAmn8OqZuNGLuBqik7XHdrT36C0YtCQ0JcoVDEcitO2ERnchA2SWBHOLRxVeJtHI wlKA==
X-Gm-Message-State: AODbwcAP8Ihs8xPi0JBta5S9wwbYxbnssRzBdxNNxdfVa0DGCUB4GJ87 iyKMELE5ossA/CvJbrO8iV6a2I4Wxgxd
X-Received: by 10.37.170.98 with SMTP id s89mr20370537ybi.19.1496361551746; Thu, 01 Jun 2017 16:59:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.93.70 with HTTP; Thu, 1 Jun 2017 16:59:10 -0700 (PDT)
In-Reply-To: <CAAZdMadDctG0sMyDV49+8UUiagqQpi0bSehtQuKPELMU-+Gg5g@mail.gmail.com>
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com> <CAAZdMacpJ-qoQt2pDBjTq6ADwmRKOHXTHDyDTzb+g2gYPvtZzQ@mail.gmail.com> <CAAF6GDdobkQh9_iqX1oU_BO9O2aK2_7Cbaper0AY4qEGYXAcvA@mail.gmail.com> <CAAZdMaeTdcgdCj26kVuq6-0EX1nmehvJJCq+YzB-4r84aRjhuA@mail.gmail.com> <CAAF6GDesLzMDN_LVYr6sFU8Z04jpXhFZphOAet-0JPsFF56Oig@mail.gmail.com> <CAAZdMadDctG0sMyDV49+8UUiagqQpi0bSehtQuKPELMU-+Gg5g@mail.gmail.com>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Thu, 01 Jun 2017 16:59:10 -0700
Message-ID: <CAAF6GDfZr_zEuttf2zQhJ9vv2T-e1Mzb3G09_auLReftSJveeg@mail.gmail.com>
To: Victor Vasiliev <vasilvv@google.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c19ad5cbf86b40550eed2fb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/m_iXF6Ll3MAWCghhPCpa51dEAcw>
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: Thu, 01 Jun 2017 23:59:15 -0000

On Thu, Jun 1, 2017 at 1:50 PM, Victor Vasiliev <vasilvv@google.com> wrote:

> I am not sure I agree with this distinction.  I can accept the difference
> in
> terms of how much attacker can retry -- but we've already agreed that
> bounding
> that number is a good idea.  I don't see any meaningful distinction in
> other
> regards.
>

It's not just a difference in the number of duplicates. With retries, the
client maintains some control, so it can do things like impose delays and
update request IDs. Bill followed up with an exactly relevant example from
Token Binding where the retry intentionally has a different token value.
That kind of control is lost with attacker driven replays.

But even if we focus on just the number; there is something special about
allowing 0 literal replays of a 0-RTT section; it is easy for users to
confirm/audit/test. If there's a hard-guaranteee that 0-RTT "MUST" never be
replayable, then I feel like we have a hope of producing a viable 0-RTT
ecosystem. Plenty of providers may screw this up, or try to cut corners,
but if we can ensure that they get failing grades in security testing
tools, or maybe even browser warnings, then we can corral things into a
zone of safety. Otherwise, with no such mechanism, I fear that bad
operators will cause the entire 0-RTT feature to be tainted and entirely
turned off over time by clients.

>
> Sure, but this is just an argument for making N small.  Also, retrys can
> also
> be directed to arbitrary nodes.
>

This is absolutely true, but see my point about the client control.
Regardless, it is a much more difficult attack to carry out. That is to
intercept and rewrite a whole TCP connection Vs grabbing a 0-RTT section
and sending it again.


>
>
>> What concerns me most here is that people are clearly being confused by
>> the TLS 1.3 draft into mis-understanding how this interacts with 0-RTT. For
>> example the X-header trick, to derive an idempotency token from the binder,
>> that one experimental deployment innovated doesn't actually work because it
>> doesn't protect against the DKG attack. We're walking into rakes here.
>>
>
> Of course it doesn't protect against the DKG attack, but nothing at that
> layer
> actually does.
>
> This sounds like an issue with the current wording of the draft.  As I
> mentioned, I believe we should be very clear on what the developers should
> and
> should not expect from TLS.
>

Big +1 :)


> So, in other words, since we're now just bargaining about the value of N,
>>> operational concerns are a fair game.
>>>
>>
>> They're still not fair game imo, because there's a big difference between
>> permitting exactly
>> one duplicate, associated with a client-driven retry, and permitting huge
>> volumes of replays. They enable different kinds of attacks.
>>
>>
> Sure, but there's a space between "one" and "huge amount".
>

It's not just quantitive, it's qualitative too. But now I'm duplicating
myself more than once ;-)


> Well in the real world, I think it'll be pervasive, and I even think it
>> /should/ be. We should make 0-RTT that safe and remove the sharp edges.
>>
>
> Are you arguing that non-safe requests should be allowed to be sent via
> 0-RTT?
> Because that actually violates reasonable expectations of security
> guarantees
> for TLS, and I do not believe that is acceptable.
>

I'm just saying that it absolutely will happen, and I don't think any kind
of lawyering about the HTTP spec and REST will change that. Folks use GETs
for non-idempotent side-effect-bearing APIs a lot. And those folks don't
generally understand TLS or have anything to do with it. I see no real
chance of that changing and it's a bit of a deceit for us to think that
it's realistic that there will be these super careful 0-RTT deployments
where everyone from the Webserver administrator to the high-level
application designer is coordinating and fully aware of all of the
implications. It crosses layers that are traditionally quite far apart.

So with that in mind, I argue that we have to make TLS transport as secure
as possible by default, while still delivering 0-RTT because that's such a
beneficial improvement.


> I do not believe that this to be the case.  The DKG attack is an attack
>>> that allows
>>> for a replay.
>>>
>>
>> It's not. It permits a retry. The difference here is that the client is
>> in full control. It can decide to delay, to change a unique request ID, or
>> even not to retry at all. But the legitimate client generated the first
>> attempt, it can be signaled that it wasn't accepted, and then it generates
>> the second attempt. If it really really needs to it can even reason about
>> the complicated semantics of the earlier request being possibly
>> re-submitted later by an attacker.
>>
>
> That's already not acceptable for a lot of applications -- and by enabling
> 0-RTT for non-safe HTTP requests, we would be pulling the rug from under
> them.
>

Yep; but I think /this/ risk is manageable and tolerable. Careful clients,
like the token binding case, can actually mitigate this. I've outlined the
scheme. For careless clients, like browsers, they can mostly ignore this;
since they retry so easily anyway, it's no worse.

But there is *no* proposed mitigation for replayable 0-RTT. So I don't
think that's manageable. Just trying to make a data-driven decision. If
someone presents an alternative mitigation (besides forbidding replays),
I'll change my mind.


> Throttling POST requests is fine -- they shouldn't go over 0-RTT, since
> they
> are not idempotent.  Throttling GET requests in this manner goes at odds
> with
> RFC 7231.
>

Throttling GET requests happens all of the time and is an important
security and fairness measure used by many deployed systems. 0-RTT would
break it. That's not ok.

I don't think it is at odds with RFC 7231 ... which also defines the 503
status code.


Incidentally, guarantee C does solve the throttling problem -- if you get N
> replays, you get promise of 1/(N+1) throttled resource available to you.
> Deployments which do this with GETs may want to deploy the measures to
> make N
> very small.  Also, since they already keep track of the state for
> throttling
> purposes, they might add a strike register on top of that.
>

One could implement a strike register like that, in the same way as a
coordinated throttling system, they have some things in common. Though it
crosses layers.

I'm all for bounded replay protection, with the bounds being 1 ;-)
>>
>
> Why not 2?  What is the difference between 1 and 2?  2 and 3?  3 and 24?
> None
> of the proposed attacks distinguishes 1 replay and N replays in qualitative
> ways (as opposed to giant semantic leap between 0 and 1 replay); only in
> how
> much damage you can do, or how much information you can extract from the
> side
> channel.
>

You keep discarding my points about client control and focusing just on the
number; but there quantitative and qualitative differences. That kind of
argument isn't very productive and doesn't move us forward.  But I've
answered above too.

-- 
Colm