Session Date/Time: 30 Apr 2025 21:00

SCONE

Summary

This virtual interim meeting of the SCONE working group focused primarily on resolving open issues and discussing a significant pull request concerning the addition of a "scone indication" mechanism. While most existing GitHub issues were deemed suitable for post-adoption discussion, the proposed scone indication generated substantial debate regarding its necessity, potential for abuse, and impact on privacy and deployment. No formal decision was reached on integrating the scone indication into the draft before adoption. The working group agreed to proceed with submitting a renamed draft (from "drone" to "scone") for an adoption call, following a mailing list confirmation of the name change.

Key Discussion Points

Working Group Status: The working group has established two work streams for protocol and semantics. Good progress has been made on the protocol work stream, and a semantic proposal has been received, which is hoped to be integrated into the protocol at some point.
Milestone: The current plan is to submit the standard track document for SCONE protocols to the IESG for publication in November 2025.
Protocol Naming (from "drone" to "scone"):
- There was a previous sense of the meeting, including a poll at a prior meeting, that the protocol name should change from "drone" to "scone" to align with the working group name.
- A pull request exists for this renaming.
- Discussion ensued on the process for confirming the name change. It was clarified that if all authors agree, they should submit a new individual draft with the updated name.
- Action Item (Chair): The chair will send an email to the mailing list to inform the community about the proposed name change and solicit feedback before initiating the working group adoption call.
Review of Open GitHub Issues:
- Most open issues were briefly reviewed and considered to be for post-adoption discussion, including topics like multi-path, SID rotation, and guidance on scone packet generation frequency.
- Issue 7 (sending an ACK) was re-confirmed as not critical for resolution prior to adoption.
- A general suggestion was made to add one-sentence summaries to GitHub issues after interim meetings and to use labels (e.g., "pre-adoption", "post-adoption", "priority") for better tracking and roadmap clarity.
Discussion on Scone Indication (Pull Request): This was the most extensive technical discussion.
- Problem Statement: Existing network elements often use Deep Packet Inspection (DPI), including trial decryption of Quick initials and parsing SNI, to identify traffic (e.g., video) for policy enforcement. This is undesirable due to privacy concerns and limitations with new privacy-enhancing technologies like ECH.
- Proposed Solution: Add a "scone indication" or hint, sent early in a flow (e.g., after the Quick initial), to inform network elements that the flow is scone-capable. This could allow network elements to potentially skip expensive DPI.
- Arguments in Favor of Indication:
  - Adoption Incentive: An indication could serve as a "carrot" for network operators to adopt scone, reducing their reliance on DPI.
  - Reduced Network Complexity: Provides a cheap way for network elements to identify scone-capable flows, potentially simplifying policy application.
  - Transition Period: Valuable during the transition when not all Quick flows are scone-enabled, allowing networks to differentiate.
  - No New Privacy Information: The indication itself does not convey new privacy-sensitive information beyond what would eventually be visible in a negotiated scone flow; it merely moves the information earlier in the flow.
  - Specific Traffic Class: Scone is particularly relevant for adaptive traffic like video. An indication could mark this class, enabling tailored network treatment (e.g., longer averaging windows for rate determination).
  - Deployment Success: Some participants believe it's a critical requirement for scone's deployment and success, as it allows network elements to treat scone flows differently from DPI-reliant flows.
- Arguments/Concerns Against Indication:
  - Abuse Potential: An indication could be abused by clients sending it on all flows (even short ones or non-adaptive traffic) to potentially get preferential treatment (e.g., better throughput, less throttling).
  - DPI Persistence: Network elements might not stop DPI entirely, as they may still need to differentiate between specific services (e.g., Facebook vs. YouTube) for policy.
  - Philosophical Stance: Some participants argued against designing a protocol that facilitates special treatment of certain types of traffic (e.g., video) over others, emphasizing the internet's principle of treating all bits equally.
  - Browser Implementation Challenges: Browsers cannot reliably know beforehand if a connection will carry video or if a website requests scone-enablement, making it difficult to decide when to send an indication without splitting connection pools or introducing new privacy-leaking APIs.
  - "You Ain't Gonna Need It" (YAGNI): Skepticism that the indication provides significant material value during the transition phase, given no guarantee that networks will cease DPI.
  - Technical "Wart": Adding an indication could introduce unnecessary complexity to the Quick handshake.
  - Lack of Guarantee: A client might send an indication, but the server might not support scone, making the indication useless.
  - Not a Must-Have: The indication was described by some as a "nice-to-have" rather than a fundamental requirement for adoption, especially considering the existence of DPI.
- Outcome of Indication Discussion: No consensus was reached at this point regarding the inclusion of the scone indication in the draft before the adoption call. The chairs indicated that this topic requires further discussion.

Decisions and Action Items

Decision: The working group will proceed with submitting a new version of the individual draft, renamed to "scone," for a working group adoption call.
Action Item (Chair): Send an email to the SCONE mailing list to inform the community about the protocol name change from "drone" to "scone" and seek any objections before the adoption call.
Action Item (Working Group): Continue the discussion on the "scone indication" pull request (PR) offline. The pull request will not be merged prior to the adoption call.
Action Item (Chairs/Editors): Consider adding brief one-sentence summaries to GitHub issues after interim meetings to capture their status and facilitate tracking. Also, explore prioritizing and labeling GitHub issues to clarify the document roadmap (e.g., "pre-adoption," "post-adoption").

Next Steps

The chairs will initiate the process for the working group adoption call for the "scone" protocol document, after confirming the name change via the mailing list.
Further discussion on the "scone indication" will take place offline.
The next virtual interim meeting is scheduled for May 21.