[Scone] Re: New draft: scone-echo

[Martin Duke <[e-mail]>]

Hi Christian, replies inline.



On Tue, Apr 21, 2026 at 11:28 PM Christian Huitema <[e-mail]>
wrote:

>
> On 4/21/2026 6:59 PM, Martin Duke wrote:
> > Hi Lucas,
> >
> > Replies inline.
> >
> > On Tue, Apr 21, 2026 at 2:00 PM Lucas Pardue <[e-mail]>
> > 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.