Re: [tcpm] Privacy problems of TCP Fast Open

Olivier Bonaventure <> Wed, 22 May 2019 07:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80B861200E6 for <>; Wed, 22 May 2019 00:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bI9xh7dvk-Dg for <>; Wed, 22 May 2019 00:10:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD50512008B for <>; Wed, 22 May 2019 00:10:26 -0700 (PDT)
Received: by with SMTP id j187so962881wmj.1 for <>; Wed, 22 May 2019 00:10:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=N8K6Gxx+cNbdGAnF5T9JAdd1hDbVPqCelEHw4EKxIno=; b=zYxKhj0OUWNpiszMcq50CvdBoaSW4pPu9N89uXuPEtTSLAhto+8edCkIbGJPqaY/2E HNVEqMJWlfDp3ydJI6lSQ5IkhQT+AHVPlce5GA1qRXVgvWDMYBG6qlvzZ4KivJwVEb9q +DtzN/B4U9nfetOzhEw8QxHp1zmycYKbXcU/cy9mzYejJqSBuQJHLe8E/svv0dKoleDs 59UIEZncwTK/P8pd8XE70YfFtidWkQ3EOrJfdAOW0iTPweUxo2ihTRQ712PqIMgO6I74 WlvbjAFZk/Og0v0sVrv20/X7hF4i3+dWLYlmpojTbxHP68nDu6sVUsnjZaqLZxH+SzIh F9rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=N8K6Gxx+cNbdGAnF5T9JAdd1hDbVPqCelEHw4EKxIno=; b=ezbPr3fYSZCHdEdBN+I3Ku61Gsn4ylqZoRXZjSQ9VHxptMm80cfIhi5bXx0YsG/Y9J 2FmsUDcjcAj0nVHZvxP/6EWf1Y7YX0rT0fzKqk5/wA19kg07gZDJZLkra7AzflIg6BFr LesX/up3RAgPk4PuLXvoKHGjZNcZgQI+aAzYD3J2bJk2v056wSOtH8/vgH7MxGYZpG3q /fTnqL91KMzGBoeqRtYaP0xGWathJCUEplIe2YsJ0dQo5pw+CQMoyFdz9wRStMv9ouFU ZxfDxydj+vA9WSFeL2EgzktAaj9SwuDV/alXF8aOyP3OMExiMRZ2JzhlsuFfAltwHMwx p+sw==
X-Gm-Message-State: APjAAAVNbeZnAi/5Zy/k63cDv6wC6U4BH56KQGTmLfleDtrIsej7Dzs0 oDll1HRqUtw6Y2vBD+mbwPmmzPxh4H/LLspTFjgXyUIqnnnKBctwnpKdipA9Vmoyc0kiM+5R
X-Google-Smtp-Source: APXvYqwpeCDWGJXy6Tvosr9EJPdU8M7O98YnpnEb7z8K5S5ZOSfgemcPTH+TW1t4XnzX9k5y7nljiA==
X-Received: by 2002:a05:600c:10ca:: with SMTP id l10mr6526051wmd.23.1558509024799; Wed, 22 May 2019 00:10:24 -0700 (PDT)
Received: from ?IPv6:2001:6a8:308f:2:473:d768:6978:2d29? ([2001:6a8:308f:2:473:d768:6978:2d29]) by with ESMTPSA id t194sm8639851wmt.3.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 00:10:23 -0700 (PDT)
From: Olivier Bonaventure <>
Message-Id: <>
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 22 May 2019 09:10:22 +0200
In-Reply-To: <>
Cc: Brian Trammell <>, Michael Tuexen <>, tcpm IETF list <>
To: Michael Welzl <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5F4E3698-3D92-43BD-B5CB-C78A3C0D069F"
Archived-At: <>
Subject: Re: [tcpm] Privacy problems of TCP Fast Open
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: Wed, 22 May 2019 07:10:31 -0000

Michael, Brian,

>> 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.

During the Prague meeting, Christoph Paasch explained that this approach is already used by a specific application. The 0-rtt convert protocol also proposes to use this approach.

> 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.

I agree, there are various techniques to deal with DoS attacks on a stack and inside specialised protocols.
> Perhaps this also answers Michael Tuexen’s comment about <>  - 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.

RFC793 authorises data in the SYN and Christoph’s explanation shows that today SYN with data but without TFO option pass through more paths than SYN with data but with a TFO option