**Session Date/Time:** 03 Nov 2025 14:30

# DISPATCH

## Summary

The DISPATCH and SICKDISPATCH working groups held a joint meeting at IETF 124 to review several proposals and direct them to appropriate venues within the IETF or IRTF, or to recommend further discussion. Key discussions included a data access protocol, AI agent discovery, source privacy in encrypted transport, zero-knowledge credentials, post-quantum deployment guidance, and an update to the TESLA authentication protocol for GNSS-SBAS. Decisions ranged from outright rejection, creation of dedicated mailing lists for further scoping, or referral to existing or future working groups/BOFs.

## Key Discussion Points

### 1. Data Access and Population Protocol (DECP)

*   **Problem Statement**: Scientific computing faces challenges with spread storage and fragmented access, non-unified querying mechanisms (incompatible metadata formats), large-scale data transfer (TB/PB level), and a lack of protocols combining streaming, security, and auditability. Existing protocols like QUIC lack application layers for data access, and MTDB3 struggles with massive data and lineage tracking.
*   **Proposed Solution (DECP)**: A Data Access and Population Protocol aiming to fill these gaps using IETF technologies and Apache Arrow Flight for high-performance columnar transport.
    *   **Core Propositions**:
        *   **Unified URL Addressing**: Standardized URI for precise data addressing from dataset to field, using Arrow binary array for efficiency.
        *   **Efficient Data Handling**: Streaming Data Frame (SDF) model supporting lazy computation, interactive PV-scale slicing, and columnar streaming leveraging Apache Arrow for high throughput (GET, PUT, POST, COOK operations).
        *   **Security & Traceability**: Token-based access control with per-request validation and multi-hop lineage tracking for auditability.
    *   **Scenarios**: Unified data addressing via standardized catalog service, large-scale data frame retrieval (zero-copy transmission for real-time sensing), and collaborative computing with real-time result synchronization and end-to-end lineage.
*   **Desired Outcome**: Direct work to an existing IETF working group for formalization, complementing QUIC and ATP3.
*   **Discussion**:
    *   **Ted Hardy**: Noted that only URI definition and port request seem appropriate for IETF; the bulk of the protocol, built on existing tools like Apache Arrow, might be better done elsewhere.
    *   **Martin Thompson**: Questioned the necessity of a new protocol, suggesting that many proposed functions could be handled by HTTP, and requested more clarity on the "novel" aspects.
    *   **Charles Eccles**: Asked about engagement with the Apache Arrow community and their interest in IETF standardization. Presenter responded no direct engagement yet but planned for future.
    *   **Mike Bishop**: Highlighted that DECP builds on Apache Arrow (not IETF) and GRPC (not IETF), suggesting significant predicate work would be needed if standardized within IETF.
*   **Decision**: The chairs concluded that this work is not appropriate for the IETF at this time.

### 2. AI Agent Discovery using DNS (Band-Aid Draft)

*   **Problem Statement**: AI agents need a reliable and scalable mechanism to discover other AI agents.
*   **Proposed Solution**: Utilize DNS due to its established governance, scalability, existing record types, and security. Suggested using DNS SVCP records and DNS service discovery for well-known entry points. Referenced existing drafts (Agent Naming Service, DNS TXT for AI agents in 6G) and a GoDaddy POC.
*   **Desired Outcome**: Progress the Band-Aid draft within a DNS-focused working group (e.g., DNSOP) or a new AI-focused working group.
*   **Discussion**:
    *   **Jonathan Rosenberg**: Mentioned an AI Protocol side meeting where discovery scope would be discussed and invited the presenter to join.
    *   **Phil Baker**: Agreed DNS could cover this, but questioned the need for new work, stating "AI is not something new." Raised trademark concerns for "Band-Aid." Suggested existing mechanisms like DANE, DANCE, DNS-SD could be unified.
    *   **John C. Klensin**: Flagged non-technical issues with DNS, such as privacy concerns and responsibility paths, which might be inherited by this application.
    *   **Roman D. (Gen AD)**: Reminded that side meetings have no standing for decisions, which should occur in official forums like DISPATCH.
    *   **Colin Jennings**: Requested clarification on the scope of discovery (single enterprise vs. internet-wide) to inform dispatch. Presenter clarified it would cover both.
*   **Decision**: Chairs suggest discussion continue in the proposed AI BOF / side meeting for further scoping and decision-making regarding a suitable working group.

### 3. Source Privacy in Encrypted Transport

*   **Problem Statement**: While ECH (Encrypted Client Hello) hides destination, client-facing servers (CDNs, hosting providers) can still observe client IP addresses and other metadata. This enables large-scale correlation and profiling, often across different legal jurisdictions, moving the internet towards centralization. This leaves a gap in end-to-end privacy for the source.
*   **Proposed Solution**: Create a lightweight relay mechanism at the edge of ISPs or network providers to protect client identity. This would improve on existing network elements (e.g., BNG, UPF) by employing methods like randomizing exit IP addresses and using ephemeral IPs/ports to reduce client exposure without significantly increasing cost or latency. An alternative mentioned was a GDPR-like legal approach.
*   **Desired Outcome**: Seek guidance on the next steps for this work within the IETF.
*   **Discussion**:
    *   **Tommy Pauly**: Acknowledged the valid privacy concerns, referencing IAB RFC 9614 on privacy partitioning. Questioned how this proposal differs from existing work in MASQUE or INT-AREA for proxy discovery.
    *   **Martin Thompson**: Suggested the proposal sounds like a NAT and questioned whether network operators would be willing to deploy such privacy-enhancing NAT devices without IETF protocol work. Recommended refining the problem statement.
    *   **Dennis Jackson**: Emphasized the need to settle on the specific technology before finding a home for the work.
    *   **Andrew Campling**: Agreed on the problem's importance and suggested dispatching to a mailing list as a first step, potentially leading to a BOF.
*   **Decision**: A dedicated mailing list will be created for further discussion and scoping of this problem.

### 4. Longfellow System for Zero-Knowledge Credentials

*   **Problem Statement**: Increasing regulatory requirements for online authentication (e.g., age verification) lead to naive solutions (uploading ID scans) that risk user data breaches. The EU's digital wallet initiative shows interest in zero-knowledge (ZK) schemes.
*   **Proposed Solution**: Longfellow, a ZK proof scheme optimized for legacy cryptography (NIST curves, SHA-256) and compatible with existing credentials (e.g., MDoc). It allows proving assertions (e.g., age) without revealing sensitive information. It has been deployed in Google Wallet (for Bumble age verification) and has open-source implementations (C++, Rust). Other ZK schemes (e.g., Microsoft Crescent) exist.
*   **Desired Outcome**: Find a suitable open venue within the IETF/IRTF for standardization, discussion, and coordination among non-profits, academics, industry, and governments.
*   **Discussion**:
    *   **Elliot Lear**: Stressed urgency, noting governments (like Switzerland) are moving ahead with e-IDs, and advocated for an IETF BOF to define a charter, suggesting CFRG/IRTF move too slowly.
    *   **Tommy Pauly**: Mentioned an upcoming IAB workshop report on age-based restrictions and an IAB open meeting to discuss it, providing a venue for related discussions.
    *   **Mark Nottingham (IAB workshop co-chair)**: Highlighted the need for coordination identified at the workshop, but cautioned against just opening a mailing list due to the "emotive" nature of the topic. Stressed the importance of scoping for any productive work (e.g., BOF).
    *   **Rowan D. (Gen AD)**: Suggested two dispatch questions: documenting existing deployment (AD-sponsored/informational) and determining the scope for a potential BOF.
    *   **Andrew Campling**: Suggested exploring if the SPICE working group (digital credentials) could be a fit.
    *   **Daniel Migault**: Argued for a dedicated "cryptographic engineering" working group for deployed, fully specified cryptography that isn't research, as current IETF/IRTF homes are inadequate.
    *   **Alissa Cooper**: Advocated for narrowing the scope to the zero-knowledge proof part (not broader age verification) and suggested a BOF leading to a working group, potentially with a relationship to CFRG for review.
    *   **Martin Thompson**: Agreed on ZKP focus but raised concerns that age verification, while currently motivating, might not be the best long-term use case, given more efficient ZKP alternatives. Reiterated the need for a BOF to thoroughly answer use case questions.
    *   **Richard Barnes**: Supported a new, focused working group, to proceed expeditiously.
    *   **Roberta**: Shared an anecdote about government interest and urgency, supporting a BOF to provide guidance while waiting for optimal solutions.
    *   **Eric Rescorla**: Stated this is complex work that needs proper cryptographic review, typically handled by CFRG, even if not strictly "research."
*   **Decision**: The chairs will discuss with the responsible ADs (Area Directors) and make a decision on the next steps, including potential BOF or working group, after further deliberation. No immediate decision was made at DISPATCH.

### 5. Guidance for Post-Quantum Deployments

*   **Problem Statement**: The IETF is experiencing a proliferation of post-quantum (PQ) specifications across working groups (e.g., LAMPS, OpenPGP), leading to a combinatorial explosion of algorithms and combinations. This makes it difficult for deployers to choose sound and ready configurations, with many options potentially immature.
*   **Proposed Solution**: Develop "crisp and terse" guidance for post-quantum deployments, not for spec developers. The presenter suggested this guidance should recommend concentrating on a limited, ready subset (e.g., hybrid KEMs) and, for now, ignoring PQ signatures for deployment.
*   **Desired Outcome**: Find an appropriate IETF venue (P-CRIP, OPS WG, AD-sponsored document) to develop and publish this guidance.
*   **Discussion**:
    *   **Mike Bishop**: Agreed on the problem of rushed signatures and supported providing guidance, potentially in PQUIP, to add a "skeptical taint."
    *   **Phil Baker**: Agreed on the general problem of algorithm obsolescence (beyond just PQ) and suggested a working group, possibly in the OPS area, to avoid vested interests.
    *   **Eric Rescorla**: Strongly opposed the idea, calling it a "rat hole" that would fail to achieve consensus due to the nuanced nature of deployments and disagreements on specific guidance. Recommended "Dev Null."
    *   **Floody (NCSC)**: Applauded the goal but agreed with Eric on the difficulty of reaching consensus on "two-bullet point" guidance due to nuance. Suggested PQUIP if it goes anywhere.
    *   **Sean Turner**: Agreed with Eric, noting TLS WG had a similar discussion recently and failed to reach consensus. Recommended letting it go.
    *   **Richard Barnes**: Suggested doing nothing or, at most, putting it in PQUIP.
    *   **Tom P.**: Disagreed with ignoring signatures, arguing that delaying the discussion would lead to future problems. Clarified that the proposal was about recommending *not deploying* certain things, not *not talking about* them.
    *   **Paul Wouters (SAC AD)**: Stated PQUIP is informative, not normative, and shouldn't set crypto rules. Agreed it would be hard to agree and would not support an AD-sponsored document ("over my dead body").
    *   **Benjamin Kaduk**: Pointed out a gap in understanding different use cases (confidentiality vs. authenticity lifetimes) and argued an exhaustive draft is impossible.
    *   **Elliot Lear (Independent Submission Editor)**: Would not entertain such a BCP document for independent submission but would be interested in a "state of affairs" document.
*   **Decision**: The discussion will be moved to the SECurity Area Group (SAG) mailing list, as there was no convergence on a specific working group or document type at DISPATCH.

### 6. Updating TESLA for GNSS-SBAS Authentication

*   **Problem Statement**: Global Navigation Satellite Systems (GNSS) are under attack (spoofing), posing significant safety risks (e.g., to aviation). The ICAO's Satellite-Based Augmentation System (SBAS) working group has selected a modified TESLA (RFC 4082) for authentication, but RFC 4082 is dated and does not fit the highly constrained bandwidth (250 bits/message) of SBAS. ICAO documents are currently not public.
*   **Proposed Solution**: Update RFC 4082 cryptographically to align with the modified TESLA being used by ICAO. This would involve a serious review and update, potentially including an appendix detailing the SBAS-specific modifications. The goal is public review of ICAO's activities and harmonizing with IETF standards.
*   **Desired Outcome**: IETF updates TESLA, either for current projects or a full review; AD-sponsored or new working group; discussion mailing list. Presenter is embedded in ICAO processes and seeking IETF engagement.
*   **Discussion**:
    *   **Rich Salz**: Deemed the proposal premature due to the unavailability of ICAO documents for public review, suggesting to "come back later."
    *   **Stuart W.**: Emphasized the extreme urgency and safety-critical nature of the work (people "live and die" from spoofing). Confirmed it's outside the DRIP WG charter. Indicated ICAO documents might be available after a meeting next week.
    *   **Britta Haller**: Expressed concern that the proposed TESLA variant is "highly insecure" and questioned whether the IETF should simply copy an insecure solution or work to "figure out how to do authentication right in aerospace."
    *   **Bob (Presenter)**: Stated that the ICAO TESLA deployment is too far along ("too late to stop that train"), and the goal is to review, fine-tune (e.g., guidance on specific crypto parameters), and publicly document it.
    *   **Christopher A.**: Asked about processes for other SDOs formally requesting RFC updates. (Chairs clarified IETF still decides).
    *   **Deb Cooley (Security AD)**: Noted a previous TESLA draft was AD-sponsored and expressed willingness to AD-sponsor again, pending document availability. Acknowledged an existing liaison arrangement between ICAO (Trust Framework Panel) and IETF.
    *   **Ted Hardy**: Raised concerns about "change control" – whether IETF would be permitted to make substantive changes. If ICAO mandates the solution, IETF involvement might be limited to review via liaison, not full standardization.
    *   **Eric Rescorla**: Reconfirmed it's outside DRIP charter and clarified there's no official *standing* liaison between ICAO and IETF, only specific liaison statements.
*   **Decision**: A dedicated mailing list will be set up to continue discussions, clarify change control, and define the scope of IETF involvement.

## Decisions and Action Items

*   **Data Access and Population Protocol (DECP)**: Deemed not appropriate for IETF work at this time.
*   **AI Agent Discovery using DNS (Band-Aid Draft)**: Discussion to continue in the proposed AI BOF / side meeting for scoping.
*   **Source Privacy in Encrypted Transport**: A dedicated mailing list will be created for further discussion and scoping.
*   **Longfellow System for Zero-Knowledge Credentials**: Chairs will discuss with ADs to determine the next steps (e.g., BOF, WG), no immediate decision.
*   **Guidance for Post-Quantum Deployments**: Discussion will be moved to the SECurity Area Group (SAG) mailing list.
*   **Updating TESLA for GNSS-SBAS Authentication**: A dedicated mailing list will be set up to continue discussions, clarify change control, and define the scope of IETF involvement.

## Next Steps

*   Chairs to initiate the creation of dedicated mailing lists for "Source Privacy in Encrypted Transport" and "Updating TESLA for GNSS-SBAS Authentication."
*   Presenters for "AI Agent Discovery" and "Zero-Knowledge Credentials" are encouraged to engage with ongoing discussions in the respective AI side meetings/proposed BOFs and with ADs.
*   The "Guidance for Post-Quantum Deployments" discussion will proceed on the SAG mailing list.