Return-Path: 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 ; 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 ; 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 ; 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 ) 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 ) id 1hTD0J-000AJC-Th; Wed, 22 May 2019 00:13:05 +0200 From: Michael Welzl 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 , Michael Tuexen , tcpm IETF list To: Brian Trammell References: <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 22:13:19 -0000 --Apple-Mail=_BCC41475-1AC5-40CA-AE63-3BF55177DD4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, See below: > On May 21, 2019, at 4:47 PM, Brian Trammell wrote: >=20 > hi Michael, >=20 > Further foolishness inside ;) >=20 >> On 21 May 2019, at 09:39, Michael Welzl wrote: >>=20 >> Hi all, >>=20 >> 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 :) >>=20 >>=20 >> So... >>=20 >>=20 >> Actually, couldn't we just remove the cookie from TFO? >>=20 >>=20 >> 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? >=20 > 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).=20 >=20 > 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. >=20 >> 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). >>=20 >> 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?" >=20 > 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).=20 >=20 > ISTM there are the following possibilities: >=20 > (1) Do nothing. >=20 > (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=20 >=20 > (2) Deprecate TFO (and hope people who want 0RTT migrate to QUIC); = explain the privacy reason behind the deprecation in the deprecated = document. >=20 > (3) Update TFO to make TFO cookies optional, and explain the = tradeoffs. >=20 > 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=E2=80=99re on the same page, I=E2=80=99m proposing = to allow handing over data from the SYN directly (with all the needed = caveats and warnings), even when there=E2=80=99s no TFO option in place. If a server doesn=E2=80=99t support this yet, it takes an RTT longer. If = a client doesn=E2=80=99t 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=E2=80=99t 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=E2=80=99s comment about = 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=E2=80=A6 e.g. limit how many of these = messages-on-SYNs an app processes per second. - the second paragraph is in conflict with what I=E2=80=99m proposing: = it talks about generating "a trivial or even a zero-length cookie=E2=80=9D= and switching to regular TFO as a fall-back. I=E2=80=99m proposing = operation without a TFO option; just relax the =E2=80=9Chow to process = data from SYN=E2=80=9D 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=E2=80=A6 just relaxing the =E2=80=9Chow to process = data-on-SYN" rule seems easier to deploy. Cheers, Michael --Apple-Mail=_BCC41475-1AC5-40CA-AE63-3BF55177DD4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99re on the same page, = I=E2=80=99m proposing to allow handing over data from the SYN directly = (with all the needed caveats and warnings), even when there=E2=80=99s no = TFO option in place.
If a server doesn=E2=80=99t support this = yet, it takes an RTT longer. If a client doesn=E2=80=99t 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=E2=80=99t 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=E2=80=99s = comment about  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=E2=80=A6 e.g. = limit how many of these messages-on-SYNs an app processes per = second.
- the second paragraph is in conflict with what I=E2=80=99= m proposing: it talks about generating "a trivial or even a zero-length = cookie=E2=80=9D and switching to regular TFO as a fall-back. I=E2=80=99m = proposing operation without a TFO option; just relax the =E2=80=9Chow to = process data from SYN=E2=80=9D 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=E2=80=A6 just relaxing the =E2=80=9Chow to process data-on-SYN" rule = seems easier to deploy.

Cheers,
Michael

= --Apple-Mail=_BCC41475-1AC5-40CA-AE63-3BF55177DD4A--