MIME-Version: 1.0
References: 
 <CAM4esxS0Lw+qSDhLydL69_v_tBKvgKbZ2u=CjrjBc9szxgSu3g@mail.gmail.com>
 <A53493F2-1925-4E2B-9F29-DD7CFBEE2EE9@cisco.com>
 <cc2383bd-df72-4738-ae72-e1f9465891c8@app.fastmail.com>
 <CAM4esxTU=cuxXM0fYVfaw25+MRdvEOoqJgeb+NfjQOyjraZi6Q@mail.gmail.com>
 <4853845b-f41f-4737-9420-ddbcf6643144@huitema.net>
In-Reply-To: <4853845b-f41f-4737-9420-ddbcf6643144@huitema.net>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 23 Apr 2026 10:48:18 -0700
Message-ID: 
 <CAM4esxQp9MN0NCdKC2hVFPVtHdddM4U_UKbDU7whijLOjjxnYw@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Content-Type: multipart/alternative; boundary="000000000000b90ff40650244133"
Message-ID-Hash: U4YS7BZX2LBJYSHC4OVCCOV3HYKZ33X6
CC: Lucas Pardue <lucas@lucaspardue.com>,
 "Sri Gundavelli (sgundave)" <sgundave=40cisco.com@dmarc.ietf.org>,
 "scone@ietf.org" <scone@ietf.org>,
 Ian Swett <ianswett=40google.com@dmarc.ietf.org>,
 "pawelj@google.com" <pawelj@google.com>,
 "mjbshaw@google.com" <mjbshaw@google.com>
Precedence: list
Subject: =?utf-8?q?=5BScone=5D_Re=3A_New_draft=3A_scone-echo?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/scone/DeLpqb__VzKhcNkusmL8V9DPCyA>

--000000000000b90ff40650244133
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Christian, replies inline.



On Tue, Apr 21, 2026 at 11:28=E2=80=AFPM Christian Huitema <huitema@huitema=
.net>
wrote:

>
> On 4/21/2026 6:59 PM, Martin Duke wrote:
> > Hi Lucas,
> >
> > Replies inline.
> >
> > On Tue, Apr 21, 2026 at 2:00=E2=80=AFPM Lucas Pardue <lucas@lucaspardue=
.com>
> > wrote:
> >
> >     I'm trying to get my head around the privacy considerations on
> >     this. The wording seems to suggest that a client QUIC
> >     implementation would, for an easy time, enable the echoing if a
> >     server advertised it. That seems to lower the barrier
> >     significantly to server "scanners" building up a detailed view of
> >     network topology with the need to expend much effort.
> >
> >
> > This is worth thinking about, though I don't believe the
> > scone-protocol draft discusses network scanning at all. In fact Sec
> > 10.1 says "QUIC implementations are therefore encouraged to make the
> > feature available unconditionally. Endpoints might send SCONE packets
> > whenever a peer can accept them.", which this draft would amplify.
>
> That another 6 bits for fingerprinting the client. So you need to say
> something about how to mitigate that in the privacy considerations.
>
> Then there are the issues of client behind a NAT. It is a way to
> distinguish end points.  Or servers behind an ECH front end, because of
> course clients, too, can send SCONE packets.
>
> I smell a spin bit.
>

I don't understand your point here. The SCONE_ECHO frame itself is
encrypted.
To observers, the only thing that changes here is that SCONE packets will
be somewhat
more likely than with vanilla SCONE.

The server can fingerprint the client more easily, I suppose, in the way
that any
transport parameter does. Is that worth saying?

Or is there some other delta from regular SCONE that I'm missing here?


>
> >     Separately, its not 100% clear to me how many SCONE_ECHO frames
> >     are expected to be sent. Is it one per packet? If so, this risks
> >     being an attack vector where the remote endpoint spams small
> >     packets and
> >     refuses to acknowledge SCONE_ECHO frames, which could cause a
> >     backlog of retransmissions. Similar to some of the issues Martin
> >     Seemann disclosed a couple if years ago.
> >
> >
> > Can you point me to that disclosure? I'm having trouble seeing
> > immediately how this is worse than not acknowledging data from an HTTP
> > request, etc, though I'm sure there's something I'm missing. I'm happy
> > to file an issue about it and add the appropriate mitigations.
> >
> > But yes, once per packet.
>
> And that's a problematic pattern -- each packet creates state on the
> client endpoint until it is acknowledged. Repeat often enough and you
> get a queue of packets all different that must all be kept. But there is
> an easy fix: specify that if packets are received out of order (per the
> packet number bit), only the last one matter; that endpoints to not need
> to repeat the frame if a frame with a higher number was acknowledged;
> and that endpoints to not have to signal each advice that they receive.
> Maybe say something about 57 seconds.
>
> -- Christian Huitema
>

Understood. Others have pointed this out and I will fix it in the next
draft.

--000000000000b90ff40650244133
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Christian, replies inline.<div><br></d=
iv><div><br></div></div><br><div class=3D"gmail_quote gmail_quote_container=
"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 21, 2026 at 11:28=E2=80=
=AFPM Christian Huitema &lt;<a href=3D"mailto:huitema@huitema.net">huitema@=
huitema.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><br>
On 4/21/2026 6:59 PM, Martin Duke wrote:<br>
&gt; Hi Lucas,<br>
&gt;<br>
&gt; Replies inline.<br>
&gt;<br>
&gt; On Tue, Apr 21, 2026 at 2:00=E2=80=AFPM Lucas Pardue &lt;<a href=3D"ma=
ilto:lucas@lucaspardue.com" target=3D"_blank">lucas@lucaspardue.com</a>&gt;=
 <br>
&gt; wrote:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0I&#39;m trying to get my head around the privacy co=
nsiderations on<br>
&gt;=C2=A0 =C2=A0 =C2=A0this. The wording seems to suggest that a client QU=
IC<br>
&gt;=C2=A0 =C2=A0 =C2=A0implementation would, for an easy time, enable the =
echoing if a<br>
&gt;=C2=A0 =C2=A0 =C2=A0server advertised it. That seems to lower the barri=
er<br>
&gt;=C2=A0 =C2=A0 =C2=A0significantly to server &quot;scanners&quot; buildi=
ng up a detailed view of<br>
&gt;=C2=A0 =C2=A0 =C2=A0network topology with the need to expend much effor=
t.<br>
&gt;<br>
&gt;<br>
&gt; This is worth thinking about, though I don&#39;t believe=C2=A0the <br>
&gt; scone-protocol draft discusses network scanning at all. In fact Sec <b=
r>
&gt; 10.1 says &quot;QUIC implementations are therefore encouraged to make =
the <br>
&gt; feature available unconditionally. Endpoints might send SCONE packets =
<br>
&gt; whenever a peer can accept them.&quot;, which this draft would amplify=
.<br>
<br>
That another 6 bits for fingerprinting the client. So you need to say <br>
something about how to mitigate that in the privacy considerations.<br>
<br>
Then there are the issues of client behind a NAT. It is a way to <br>
distinguish end points.=C2=A0 Or=C2=A0servers behind an ECH front end, beca=
use of <br>
course clients, too, can send SCONE packets.<br>
<br>
I smell a spin bit.<br></blockquote><div><br></div><div>I don&#39;t underst=
and your point here. The SCONE_ECHO frame itself is encrypted.</div><div>To=
 observers, the only thing that changes here is that SCONE packets will be =
somewhat</div><div>more likely than with vanilla SCONE.</div><div><br></div=
><div>The server can fingerprint the client more easily, I suppose, in the =
way that any<br>transport parameter does. Is that worth saying?</div><div><=
br></div><div>Or is there some other delta from regular SCONE that I&#39;m =
missing here?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
<br>
&gt;=C2=A0 =C2=A0 =C2=A0Separately, its not 100% clear to me how many SCONE=
_ECHO frames<br>
&gt;=C2=A0 =C2=A0 =C2=A0are expected to be sent. Is it one per packet? If s=
o, this risks<br>
&gt;=C2=A0 =C2=A0 =C2=A0being an attack vector where the remote endpoint sp=
ams small<br>
&gt;=C2=A0 =C2=A0 =C2=A0packets and<br>
&gt;=C2=A0 =C2=A0 =C2=A0refuses to acknowledge SCONE_ECHO frames, which cou=
ld cause a<br>
&gt;=C2=A0 =C2=A0 =C2=A0backlog of retransmissions. Similar to some of the =
issues Martin<br>
&gt;=C2=A0 =C2=A0 =C2=A0Seemann disclosed a couple if years ago.<br>
&gt;<br>
&gt;<br>
&gt; Can you point me to that disclosure? I&#39;m having trouble seeing <br=
>
&gt; immediately how this is worse than not acknowledging data from an HTTP=
 <br>
&gt; request, etc, though I&#39;m sure there&#39;s something I&#39;m missin=
g. I&#39;m happy <br>
&gt; to file an issue about it and add the appropriate mitigations.<br>
&gt;<br>
&gt; But yes, once per packet.<br>
<br>
And that&#39;s a problematic pattern -- each packet creates state on the <b=
r>
client endpoint until it is acknowledged. Repeat often enough and you <br>
get a queue of packets all different that must all be kept. But there is <b=
r>
an easy fix: specify that if packets are received out of order (per the <br=
>
packet number bit), only the last one matter; that endpoints to not need <b=
r>
to repeat the frame if a frame with a higher number was acknowledged; <br>
and that endpoints to not have to signal each advice that they receive. <br=
>
Maybe say something about 57 seconds.<br>
<br>
-- Christian Huitema<br></blockquote><div><br></div><div>Understood. Others=
 have pointed this out and I will fix it in the next draft.=C2=A0</div></di=
v></div>

--000000000000b90ff40650244133--