There have been several messages asking similar questions on DNSOP recently. Maybe we should write an FAQ for SVCB...
As I wrote in previous discussions on this topic [1][2]: 1. SVCB generally assumes that you are connecting to a service identified by (part of) a URI, including a scheme. What is the URI in this case? If there is none, SVCB is likely not the right solution. 2. It sounds like you are assuming that agents are identified by domain names, but are operating in a HTTP-centric world. In an HTTP-centric world, it's probably better to let agents be identified by an HTTP resource, so that they can be created and modified more easily. (There are also privacy advantages.) 3. It looks like this proposal is trying to fetch HTTP resources that are authenticated by a non-HTTP signature chain. This is a lot more complicated than a solution using standard HTTP server authentication, and the benefit is not clear to me. --Ben Schwartz [1] https://mailarchive.ietf.org/arch/msg/dnsop/8v6J897lNyVil4zW3hsR8xGbExw/ [2] https://mailarchive.ietf.org/arch/msg/dnsop/EUpxbLgilznpyJgaaR7GZwleqOw/ On Sun, May 17, 2026 at 6:15 PM Enrique Somoza <[email protected]> wrote: > Hi dnsop, This is a cross-post pointer from my dmsc thread earlier today > on draft-somoza-atn-agent-trust-negotiation-00. The draft sits primarily in > dmsc but registers SVCB ParamKeys, so I wanted to give dnsop visibility on > the DNS-layer content > > Hi dnsop, > > This is a cross-post pointer from my dmsc thread earlier today on > draft-somoza-atn-agent-trust-negotiation-00. The draft sits primarily in > dmsc but registers SVCB ParamKeys, so I wanted to give dnsop visibility on > the DNS-layer content specifically. > > The dnsop-relevant part is small. The draft requests two SVCB ParamKey > registrations: > > atn URI Absolute HTTPS URI pointing to an ATN Index > Document > atn-digest hex-string SHA-256 digest of the Index Document for > integrity binding > > It also proposes the same two names as TXT key=value tags for > compatibility with existing TXT-based agent discovery records (notably AID). > > The integrity model: the digest is bound to the content at the URL, not > the DNS lookup itself. This is the same model as Subresource Integrity in > web platforms. DNSSEC remains useful for authenticating the binding; the > digest covers the artifact after fetch. The draft requires JWS signature on > the Index Document when DNSSEC is not validated, and makes it RECOMMENDED > but not REQUIRED when DNSSEC is in use. > > Questions where I would value dnsop input: > > 1. The name pattern. "atn" and "atn-digest" mirrors patterns in existing > TXT-based discovery drafts. Is there a dnsop preference for the integrity > field name (e.g., "atn-i", "atn-sha256", etc.) before this goes anywhere > near IANA? > > 2. Allocation path. The draft is Experimental. Is the right path: (a) > provisional allocation from the private-use range during the Experimental > period, (b) early allocation with WG sponsorship, or (c) wait until > standards-track maturity? > > 3. SVCB vs TXT. The draft offers both forms for compatibility with the > discovery proposals already in flight (AID uses TXT; DNS-AID uses SVCB). > Should ATN deprecate the TXT form and require SVCB given dnsop's general > direction? > > 4. DNSSEC interaction. The current language ("RECOMMENDED but not REQUIRED > when DNSSEC is in use") may be too permissive. Should JWS-on-Index be MUST > regardless? > > The draft itself is at: > > https://datatracker.ietf.org/doc/draft-somoza-atn-agent-trust-negotiation/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-somoza-atn-agent-trust-negotiation/__;!!Bt8RZUm9aw!5LBAuicD5Zum5Csa-GkjTXR_TGt1AazU8V9MEbNqSPz-ybsAYd_hxPXryqdXN-Z5LCv_oVJR_9tjMA$> > > The DNS Binding section is Section 4 and is short. > > Thanks, > Enrique > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
