Re: [tcpm] Privacy problems of TCP Fast Open

Michael Welzl <michawe@ifi.uio.no> Tue, 21 May 2019 22:13 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C703712029D for <tcpm@ietfa.amsl.com>; Tue, 21 May 2019 15:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 GZXHyq2NYAKl for <tcpm@ietfa.amsl.com>; Tue, 21 May 2019 15:13:11 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FFA120232 for <tcpm@ietf.org>; Tue, 21 May 2019 15:13:10 -0700 (PDT)
Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1hTD0L-0000Oq-Te; Wed, 22 May 2019 00:13:05 +0200
Received: from 223.247.16.62.customer.cdi.no ([62.16.247.223] helo=[10.0.0.8]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1hTD0J-000AJC-Th; Wed, 22 May 2019 00:13:05 +0200
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <9F56B293-307F-4CE8-BD10-117F792CF272@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BCC41475-1AC5-40CA-AE63-3BF55177DD4A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Wed, 22 May 2019 00:13:01 +0200
In-Reply-To: <491A06E5-1D3C-46BF-B682-FBFB9B752906@trammell.ch>
Cc: Erik Sy <sy@informatik.uni-hamburg.de>, Michael Tuexen <michael.tuexen@lurchi.franken.de>, tcpm IETF list <tcpm@ietf.org>
To: Brian Trammell <ietf@trammell.ch>
References: <ba3887b6-1554-9a67-8834-4bb598cf18f0@informatik.uni-hamburg.de> <fd9f22b0-03ee-a1ef-ee97-02a93bf2648b@informatik.uni-hamburg.de> <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <7B148CBB-3D8A-4D29-BCA7-0B241E548D4E@ifi.uio.no> <491A06E5-1D3C-46BF-B682-FBFB9B752906@trammell.ch>
X-Mailer: Apple Mail (2.3445.104.8)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 62.16.247.223 is neither permitted nor denied by domain of ifi.uio.no) client-ip=62.16.247.223; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.8];
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 983132B18C42CAF9F8950C8CF58B3E267B9669DB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/Q2dVRamwJsqe-5CPo-61hiavBBA>
Subject: Re: [tcpm] Privacy problems of TCP Fast Open
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2019 22:13:19 -0000

Hi,

See below:

> On May 21, 2019, at 4:47 PM, Brian Trammell <ietf@trammell.ch>; wrote:
> 
> hi Michael,
> 
> Further foolishness inside ;)
> 
>> On 21 May 2019, at 09:39, Michael Welzl <michawe@ifi.uio.no>; wrote:
>> 
>> Hi all,
>> 
>> I'm about to make a fool of myself because I'm quite certain that I'm missing something.
>> But, I guess this is worth the risk - somehow I'm not risking much, as most people on this list already know me well enough to not be surprised by another foolish idea coming from me   :)
>> 
>> 
>> So...
>> 
>> 
>> Actually, couldn't we just remove the cookie from TFO?
>> 
>> 
>> As far as I understand, the main point of the cookie is to protect the server against clients that might spoof their IP addresses and just send tons of requests to the server - which could potentially be much heavier to handle than just the SYN state without TFO.
>> To some degree, this is an OS problem, not a network problem: methods could be in place to limit the time an application spends answering requests that are carried on SYNs. My question is: wouldn't that be enough?
> 
> All simple cookie based-approaches have a pretty simple tradeoff: use a cookie which references some previous visible exchange between client and server, trading off load reduction on the server (and flexibility in deployment of DoS protection in front of the server) for traceability (which, in this case, is a requirement, not something to be avoided). The design of TFO (and SYN cookies before it). 
> 
> More advanced 0RTT tokens have a different tradeoff; since the token is established between client and server without being observable on the path, here we gain traceability protection and retain server load reduction, but give up the ability to have front-ends that can reject attack traffic without some form of coordination with the server.
> 
>> A few years ago, I'm sure that such a proposal would have been shot by people saying that data carried by TCP is general and TCP must serve all applications, and that we can't have that kind of special treatment for data arriving via SYNs.
>> However, TFO has already departed from this generality, in several ways: applications using it must be able to handle incoming duplicate requests; they need to use special API calls to access the data; importantly (for the point I'm making), rate limits should already be in place when using TFO (RFC 7413, section 5.1).
>> 
>> So what I'm proposing is: couldn't we re-write TFO to just remove the Cookie from it, and say: "it's allowed for applications to accept data that comes with a SYN right away, but this must be done in a special way (as already described in RFC 7413), and in particular, the time an application spends processing TFO requests must be limited to avoid being DDoSed?"
> 
> You're correct to point out that 0RTT resumption is and will always remain special, not only due to the special requirements it places on applications but also for cryptographic reasons (0RTT cannot be made forward-secret, so data sent in 0RTT for TLS1.3 or QUIC has different cryptographic properties than the rest of the session). 
> 
> ISTM there are the following possibilities:
> 
> (1) Do nothing.
> 
> (1a) Do nothing, but issue guidance in an informational RFC notinf that TFO cookies are traceable, and should be avoided in the open Internet when 
> 
> (2) Deprecate TFO (and hope people who want 0RTT migrate to QUIC); explain the privacy reason behind the deprecation in the deprecated document.
> 
> (3) Update TFO to make TFO cookies optional, and explain the tradeoffs.
> 
> I would expect pushback on 2 or 3 from people running TFO on the Internet, because it requires coordinated implementation effort and changes the operational environment (which always carries risk).

Why would 3 require coordinated implementation effort?
Just to make sure we’re on the same page, I’m proposing to allow handing over data from the SYN directly (with all the needed caveats and warnings), even when there’s no TFO option in place.
If a server doesn’t support this yet, it takes an RTT longer. If a client doesn’t support this yet (and hence only puts in data on a SYN *with* the TFO option), nothing bad happens, except that there are the privacy concerns that kicked off this thread. When a client doesn’t support this and does *not* put data on a SYN, nothing special happens. This seems like a good gradual upgrade path for me.
Regarding front-ends, I guess they could make rejection decisions when they see too many SYNs carrying data with or without a TFO option.

Perhaps this also answers Michael Tuexen’s comment about  https://tools.ietf.org/html/rfc7413#section-7.3 <https://tools.ietf.org/html/rfc7413#section-7.3>  - which has similarities, but:
- the first paragraph sounds a bit too limiting: I mean this as a general use thing, just like TFO, only with the caveat of having to limit the load somehow… e.g. limit how many of these messages-on-SYNs an app processes per second.
- the second paragraph is in conflict with what I’m proposing: it talks about generating "a trivial or even a zero-length cookie” and switching to regular TFO as a fall-back. I’m proposing operation without a TFO option; just relax the “how to process data from SYN” rule and state all the necessary warnings.


> There is the caveat that I'm not sure how many are running TFO on the Internet. (I do know Google was the biggest one, at least a couple of years ago, from research I did before joining).

Yep, that too… just relaxing the “how to process data-on-SYN" rule seems easier to deploy.

Cheers,
Michael