netdev - Re: [PATCH v1 net-next 1/4] tcp: Make TFO client fallback behaviour consistent.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <80bb29a8-290c-449e-a38d-7d4e47ce882e@wizmail.org>
Date: Sat, 18 Oct 2025 22:17:12 +0100
From: Jeremy Harris <jgh@...mail.org>
To: Kuniyuki Iwashima <kuniyu@...gle.com>
Cc: Neal Cardwell <ncardwell@...gle.com>,
 "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 Yuchung Cheng <ycheng@...gle.com>, Willem de Bruijn <willemb@...gle.com>,
 Kuniyuki Iwashima <kuni1840@...il.com>, netdev@...r.kernel.org,
 Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH v1 net-next 1/4] tcp: Make TFO client fallback behaviour
 consistent.

On 2025/10/18 9:56 PM, Kuniyuki Iwashima wrote:
>> In addition, a client doing this (SYN with cookie but no data) is granting
>> permission for the server to respond with data on the SYN,ACK (before
>> 3rd-ACK).
> 
> As I quoted in patch 2, the server should not respond as such
> for SYN without payload.
> 
> https://datatracker.ietf.org/doc/html/rfc7413#section-3
> ---8<---
>     Performing TCP Fast Open:
> 
>     1. The client sends a SYN with data and the cookie in the Fast Open
>        option.
> 
>     2. The server validates the cookie:
> ...
>     3. If the server accepts the data in the SYN packet, it may send the
>        response data before the handshake finishes.
> ---8<---

In language lawyer terms, that (item 3 above) is a permission.  It does
not restrict from doing other things.  In particular, there are no RFC 2119
key words (MUST NOT, SHOULD etc).

I argue that once the server has validated a TFO cookie from the client,
it is safe to send data to the client; the connection is effectively open.

For traditional, non-TFO, connections the wait for the 3rd-ACK is required
to be certain that the IP of the alleged client, given in the SYN packet,
was not spoofed by a 3rd-party.  For TFO that certainty is given by the
cookie; the server can conclude that it has previously conversed with
the source IP of the SYN.

Alternately, one could read "the data" in that item 3 as including "zero length data";
the important part being accepting it.
-- 
Cheers,
   Jeremy