Return-Path: X-Original-To: scone@mail2.ietf.org Delivered-To: scone@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 881C4E07F798 for ; Tue, 21 Apr 2026 19:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776826735; bh=uR1Oe+q3zj0Zj9WjkG/tcWW+fMnw80ol+cI+t9EgHa8=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=Yo2vtr5dYGVhnqqJO475gXCJ7i1VPlMrzUth1QfyUJxYd7raMDbmitPM1xep11oZ2 2Uni5/RKBjd1bpfAVkgii9iFUaOIrs/So/rY0pdsN0ovlrnpQ8fqJbzChi87LWEEy/ 56HdrFAMzu2EkcgR4OfefwMI5RtI6vShEfiZr1/8= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=lucaspardue.com header.b="aX6qKriu"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="APvSRJcl" Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_Ui7KulJ-5B for ; Tue, 21 Apr 2026 19:58:54 -0700 (PDT) Received: from fout-a4-smtp.messagingengine.com (fout-a4-smtp.messagingengine.com [103.168.172.147]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id B79E4E07F6D8 for ; Tue, 21 Apr 2026 19:58:40 -0700 (PDT) Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfout.phl.internal (Postfix) with ESMTP id 63F3EEC00CC; Tue, 21 Apr 2026 22:58:40 -0400 (EDT) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-02.internal (MEProxy); Tue, 21 Apr 2026 22:58:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucaspardue.com; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1776826720; x= 1776913120; bh=uR1Oe+q3zj0Zj9WjkG/tcWW+fMnw80ol+cI+t9EgHa8=; b=a X6qKriuCWHVMMvDSIn7ddwZ6V9YMRXQoOE4m+sPGzjKJdSmyO4bvZSeBKQV9Bf43 OZvKMC1+pX9UAQoK5/9nQwlHCuWj1xikdwh0YIt5wQ/JVxUcku9UPWR8JVGDL3eq Nn/QPOWXqLJnfy+wNyRqR4ymjyLE+KtlKB+LgGu7PG5+G4mJDxlSkHP91ltNpj81 Y2PmRC2FaAyDEDVXJSG88UyzkqpzGOz32zP0Z4TOi6VpDLgpAB2V0yFw8TXTLASA E/MZcoDAphXXxVxAfkPubvhBBQ+eETBFleqcuD/Ih34GtuZBApyXiBQVofGyw5s7 uw2RHFjPK1n6KfXvEY90A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1776826720; x=1776913120; bh=uR1Oe+q3zj0Zj9WjkG/tcWW+fMnw80ol+cI +t9EgHa8=; b=APvSRJcle0CQMlpN0bmqkJIcl/b+cvCrgbaIY2OuwksxzczJX34 mLtl1Cd+6OCsYOqsE42oHAzlHXJl+lOqOquZo2J8VfHLoczkT5tYcVRkRdEh1teH EV9e/q9oeTKidAl1Kd1ujuw11Ft5uRjugEv9aodfAc9FKYeq6pJ+/ZnS4dVX6aEP qN2j5lMtpzF4FrFUAs3AUree69PzNVAcLjZcpC18OtvEGU4bXn0w+roP3FWZK2yY LBd9NNCaZGuPqM6XTCx5s6cadHSpMlaxiTR7ZIVdaygjOdQTU0QjSglS8LABirIO HrBGZmuVbYjrm/6VMPvTCzrwgVGZI0IdGpQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdeifedufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenogfuuh hsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpefoggffhffvvefkjghfufgtsegr tderreertdejnecuhfhrohhmpedfnfhutggrshcurfgrrhguuhgvfdcuoehluhgtrghsse hluhgtrghsphgrrhguuhgvrdgtohhmqeenucggtffrrghtthgvrhhnpedvkedutdfhvdef heekfedtvdehtdelkeejtdfhffekueelvdejvedtgffgleegfeenucffohhmrghinhepgh hithhhuhgsrdhiohdpphhhohhnvghhohhmvgdrnhgvthdphhhtthhprhgvqhhuvghsthgv thgtthhhohhughhhihhmshhurhgvthhhvghrvghsshhomhgvthhhihhnghhimhhmihhssh hinhhgrdhimhdpshgvvghmrghnnhdrihhopdhivghtfhdrohhrghdpghhithhhuhgsrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheplh hutggrsheslhhutggrshhprghrughuvgdrtghomhdpnhgspghrtghpthhtohepiedpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtohepihgrnhhsfigvthhtpeegtdhgohhoghhlvg drtghomhesughmrghrtgdrihgvthhfrdhorhhgpdhrtghpthhtohepshhguhhnuggrvhgv peegtdgtihhstghordgtohhmsegumhgrrhgtrdhivghtfhdrohhrghdprhgtphhtthhope hmrghrthhinhdrhhdrughukhgvsehgmhgrihhlrdgtohhmpdhrtghpthhtohepmhhjsghs hhgrfiesghhoohhglhgvrdgtohhmpdhrtghpthhtohepphgrfigvlhhjsehgohhoghhlvg drtghomhdprhgtphhtthhopehstghonhgvsehivghtfhdrohhrgh X-ME-Proxy: Feedback-ID: i23b94938:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 348E03020073; Tue, 21 Apr 2026 22:58:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: AzBcsNs2_wL3 Date: Wed, 22 Apr 2026 03:58:18 +0100 From: "Lucas Pardue" To: "Martin Duke" Message-Id: <21c638b7-37d2-4556-9f44-3a28f91980d4@app.fastmail.com> In-Reply-To: References: Content-Type: multipart/alternative; boundary=b4bd3c7388a8aad0d9ed4b74c8b45010dd794b4e Message-ID-Hash: WMCBATXA64L5WW623WXAB3C6LRKGP2UE X-Message-ID-Hash: WMCBATXA64L5WW623WXAB3C6LRKGP2UE X-MailFrom: lucas@lucaspardue.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "Sri Gundavelli (sgundave)" , "scone@ietf.org" , Ian Swett , "pawelj@google.com" , "mjbshaw@google.com" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BScone=5D_Re=3A_New_draft=3A_scone-echo?= List-Id: Standard Communication with Network Elements WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --b4bd3c7388a8aad0d9ed4b74c8b45010dd794b4e Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 22, 2026, at 02:59, Martin Duke wrote: > Hi Lucas, >=20 > Replies inline. >=20 > On Tue, Apr 21, 2026 at 2:00=E2=80=AFPM Lucas Pardue 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, fo= r an easy time, enable the echoing if a server advertised it. That seems= to lower the barrier significantly to server "scanners" building up a d= etailed view of network topology with the need to expend much effort. >=20 > This is worth thinking about, though I don't believe the scone-protoco= l draft discusses network scanning at all. In fact Sec 10.1 says "QUIC i= mplementations are therefore encouraged to make the feature available un= conditionally. Endpoints might send SCONE packets whenever a peer can ac= cept them.", which this draft would amplify. Yeah, I won't profess to be an expert in core SCONE but the proposal in = SCONE-Echo seems it might shift the stakes a bit from: client advertises= support to receive and consume with some implied user consent invoked w= hen crossing the transport->app layer, to: server can harvest informatio= n without application binding context to the consent.=20 For example, if a client side API was available to access SCONE informat= ion in a browser, we might imagine it to be modelled around the approach= in the Network Information API [1]. In particular, the Interface sectio= n defines some fields that might be used to echo information from the cl= ient to the server, with the statement=20 > They can do that via the Client Hints infrastructure defined in [CLIEN= T-HINTS ] and bound by= the processing model defined in [CLIENT-HINTS-INFRASTRUCTURE ]. Those docs describe some privacy considerations [3]. Some of which might= not be relevant to this proposal. For instance, by only allowing a sing= le connection to report information only about it's own connection, you = narrow some of the cross origin concerns.=20 Conversely, by pushing this so far down the stack, it would seem to be t= rivial for any party to gather SCONE information with minimal user conte= xt. Imagine a web page on example.org that gets some malicious JavaScrip= t injected that connects to phonehome.net. Upon establishing a connectio= n to it, SCONE echo allows a server to probe the client's path for SCONE= information without having to do much other than send PING frames. The client hints approach quoted above builds upon a sequence of interac= tions that attempt to address same origin and cross origin matters. Alth= ough I won't claim that its perfect. To summarise, SCONE's concerns about consent to _receive_ data seems sli= ghtly different to SCONE echo's concerns about consent to beacon that da= ta. =20 > =20 >>=20 >> Separately, its not 100% clear to me how many SCONE_ECHO frames are e= xpected to be sent. Is it one per packet? If so, this risks being an att= ack vector where the remote endpoint spams small packets and=20 >> refuses to acknowledge SCONE_ECHO frames, which could cause a backlog= of retransmissions. Similar to some of the issues Martin Seemann disclo= sed a couple if years ago. >=20 > Can you point me to that disclosure? I'm having trouble seeing immedia= tely 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 a= n issue about it and add the appropriate mitigations. >=20 > But yes, once per packet. Thanks for the clarification. I wont claim to have done a deep security = analysis of your proposal but its probably worth reading Marten's blog p= ost on DoS via CID management frame backlog [4]. The crux of the issue i= s that the attacker can manipulate the victim to respond with mandatory = frames, together with the victim's ability to actually respond. The difference with HTTP, to my mind at least, is that implementations a= lready tend to have protections in place for monitoring state commitment= s to individual requests. For instance, the size of buffers or duration = of a transaction.=20 Marten's blog explores some of the potential mitigations. One difference= with SCONE echo, I _think_, is that the QUIC-layer requirements to resp= ond do not depend on the peers authenticated packet payload. Just the pr= esence of a packet. This might make it easier to exploit. A more defensi= ve approach might be to require the peer to actively request SCONE infor= mation and add flow control so the local endpoint has fine-grain control= over the number of such requests that can be issued at any one time.=20 Cheers Lucas [1] https://wicg.github.io/netinfo [2] https://wicg.github.io/netinfo/#networkinformation-interface [3] https://wicg.github.io/netinfo/#privacy-considerations [4] https://seemann.io/posts/2024-03-19---exploiting-quics-connection-id= -management/ > =20 >>=20 >> Cheers >> Lucas >>=20 >> On Tue, Apr 21, 2026, at 21:39, Sri Gundavelli (sgundave) wrote: >>> Hi Martin, >>> =20 >>> Thanks for writing this document. This was the missing piece. >>> =20 >>> =20 >>> BR! >>> Sri >>> =20 >>> =20 >>>=20 >>> Cisco Confidential >>>=20 >>> *From: *Martin Duke >>> *Date: *Tuesday, April 21, 2026 at 1:28=E2=80=AFPM >>> *To: *"scone@ietf.org" >>> *Cc: *Ian Swett , "pawelj@go= ogle.com" , "mjbshaw@google.com" >>> *Subject: *[Scone] New draft: scone-echo >>> =20 >>> Hello SCONE, >>> =20 >>> I've published a new internet-draft: >>> https://datatracker.ietf.org/doc/draft-duke-scone-scone-echo/ >>> =20 >>> Basically, it's a QUIC extension to report bandwidth advice back to = the SCONE sender in a QUIC frame. We have some edge cases where the send= er can do useful things with this advice but the receiving application i= s unable to cooperate. See the intro for a somewhat more thorough discus= sion of that. >>> =20 >>> The relevant chairs/AD agreed this should sit in SCONE and not QUICW= G, although it may need a recharter. >>> =20 >>> Anyway, if this interests you, take a look and file issues in the gi= thub . >>> =20 >>> Thanks, >>> Martin >>> _______________________________________________ >>> Scone mailing list -- scone@ietf.org >>> To unsubscribe send an email to scone-leave@ietf.org >>>=20 >>=20 --b4bd3c7388a8aad0d9ed4b74c8b45010dd794b4e Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 22, 2026, at 02:59, Martin Duke wrote:
Hi Lucas,

Replies inline.
=

On Tue, Apr 21, 2026 at 2:0= 0=E2=80=AFPM Lucas Pardue <l= ucas@lucaspardue.com> wrote:

I'm trying to get my head arou= nd the privacy considerations on this. The wording seems to suggest that= a client QUIC implementation would, for an easy time, enable the echoin= g if a server advertised it. That seems to lower the barrier significant= ly 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 fe= ature available unconditionally. Endpoints might send SCONE packets when= ever a peer can accept them.", which this draft would amplify.
Yeah, I won't profess to be an expert in core = SCONE but the proposal in SCONE-Echo seems it might shift the stakes a b= it from: client advertises support to receive and consume with some impl= ied user consent invoked when crossing the transport->app layer, to: = server can harvest information without application binding context to th= e consent.

For example, if a client side API w= as available to access SCONE information in a browser, we might imagine = it to be modelled around the approach in the Network Information API [1]= . In particular, the Interface section defines some fields that might be= used to echo information from the client to the server, with the statem= ent 

> They can do that via the Cl= ient Hints infrastructure defined in [CLIENT-HINTS] and bound by the processing= model defined in [CLIENT-HINTS-INFRASTRUCTURE].

<= /div>
Those docs describe some privacy considerations [3]. Some of w= hich might not be relevant to this proposal. For instance, by only allow= ing a single connection to report information only about it's own connec= tion, you narrow some of the cross origin concerns.

Conversely, by pushing this so far down the stack, it would seem t= o be trivial for any party to gather SCONE information with minimal user= context. Imagine a web page on example.org that gets some malicious Jav= aScript injected that connects to phonehome.net. Upon establishing a con= nection to it, SCONE echo allows a server to probe the client's path for= SCONE information without having to do much other than send PING frames= .

The client hints approach quoted above builds= upon a sequence of interactions that attempt to address same origin and= cross origin matters. Although I won't claim that its perfect.

To summarise, SCONE's concerns about consent to _receiv= e_ data seems slightly different to SCONE echo's concerns about consent = to beacon that data.

 
 

Separately, its not 100% cle= ar to me how many SCONE_ECHO frames are expected to be sent. Is it one p= er packet? If so, this risks being an attack vector where the remote end= point spams small packets and 
refuses to acknowledge SCO= NE_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 tha= n not acknowledging data from an HTTP request, etc, though I'm sure ther= e's something I'm missing. I'm happy to file an issue about it and add t= he appropriate mitigations.

But yes, once per p= acket.

Thanks for the = clarification. I wont claim to have done a deep security analysis of you= r proposal but its probably worth reading Marten's blog post on DoS via = CID management frame backlog [4]. The crux of the issue is that the atta= cker can manipulate the victim to respond with mandatory frames, togethe= r with the victim's ability to actually respond.

The difference with HTTP, to my mind at least, is that implementations= already tend to have protections in place for monitoring state commitme= nts to individual requests. For instance, the size of buffers or duratio= n of a transaction. 

Marten's blog explore= s some of the potential mitigations. One difference with SCONE echo, I _= think_, is that the QUIC-layer requirements to respond do not depend on = the peers authenticated packet payload. Just the presence of a packet. T= his might make it easier to exploit. A more defensive approach might be = to require the peer to actively request SCONE information and add flow c= ontrol so the local endpoint has fine-grain control over the number of s= uch requests that can be issued at any one time. 

Cheers
Lucas

[1] https://wicg.github.io/netinfo
 
<= br>
Cheers
Lucas

On Tue, Ap= r 21, 2026, at 21:39, Sri Gundavelli (sgundave) wrote:

Hi= Martin,

 

Thanks for writing this document. This was the missing piece.<= /span>

 

 

BR!

Sri

=  

<= p class=3D"qt-m_1085703629724949936qt-MsoNormal"> 


Cisco Confidential

From: Martin Duke <martin.h.duke@gmail.com>
Date: Tuesday, Ap= ril 21, 2026 at 1:28=E2=80=AFPM
To: "scone@ietf.org" <scone@ietf.org>
Cc: Ia= n Swett <ianswett=3D40google.com@dmarc.ietf.org>, "pawelj@google.com" <pawelj@google.com>, = "mjbshaw@google.= com" <mjb= shaw@google.com>
Subject: [Scone] New draft: scone-ech= o

 

Hello SCONE,

 

I've published a new internet-draft:

 

Basically, it's a QUIC exten= sion to report bandwidth advice back to the SCONE sender in a QUIC frame= . We have some edge cases where the sender can do useful things with thi= s advice but the receiving application is unable to cooperate. See=0A th= e intro for a somewhat more thorough discussion of that.

<= p class=3D"qt-m_1085703629724949936qt-MsoNormal"> 

The relevant chairs/AD a= greed this should sit in SCONE and not QUICWG, although it may need a re= charter.

 

= Anyway, if this interests you, take a look and file issues in the <= a href=3D"https://github.com/martinduke/scone-echo" target=3D"_blank">gi= thub.

 

Thanks,
Martin

__________________________= _____________________
Scone mailing list -- scone@ietf.org
To u= nsubscribe send an email to scone-leave@ietf.org



--b4bd3c7388a8aad0d9ed4b74c8b45010dd794b4e--