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] [day] [month] [year] [list]

Message-ID: <CAAVpQUC489+RpEcyaHqrR0HpTG-SO9_ty-n7R1e_HnjGzD-2PA@mail.gmail.com>
Date: Mon, 20 Oct 2025 18:28:37 -0700
From: Kuniyuki Iwashima <kuniyu@...gle.com>
To: Yuchung Cheng <ycheng@...gle.com>
Cc: Jeremy Harris <jgh@...mail.org>, 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>, 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 Mon, Oct 20, 2025 at 9:31 AM Yuchung Cheng <ycheng@...gle.com> wrote:
>
> On Sat, Oct 18, 2025 at 2:17 PM Jeremy Harris <jgh@...mail.org> wrote:
> >
> > 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.
>
> Thanks for the patch. But indeed this was the intentional design (i.e.
> empty MSG_FASTOPEN call triggers server immediate accept and send
> before final ACK in 3WHS). It's allowing more application scenarios
> for TFO. Now some applications may have taken advantage of this design
> so this patch set may break them.

I see.  I'll leave the 0-byte send as is and make the error path of
tcp_wmem_schedule() align with others.

What do you think about the edge case in patch 2 description ?
Actually, this patch was a prep to detect the case easily.

The script could be valid if the server set the no cookie option,
but it cannot be detected on the client side. (and no cookie feature
is not an official feature in RFC)


>
> But the RFC could be more specific about this edge case so revising
> the RFC as an errata?

Sure, I can post an errata like

3. If the server accepts the SYN packet with a valid TFO cookie,
   it may send the response data before the handshake finishes.

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