[Web-bot-auth] Re: DNS-rooted key discovery for Signature-Agent: a DANE/TLSA complement to the .well-known directory

[Blake <[e-mail]>]

Kaveh,

You said you'd carry the record-type question to DANCE, so this is one
for you to take with it rather than for the thread.

There's a third option between overloading TLSA and minting a new RR.
draft-morrison-mcp-dns-discovery-04 puts an Ed25519-signed identity
envelope, binding a handle to a public key, a log root and a revocation
commitment, in a TXT record under a signed zone. The signature covers
the envelope, so the record type asserts nothing and TLSA is left doing
TLS. The DNSSEC dependency lands on this too.

  https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-discovery/

If you'd rather I brought it there myself, say so and I will.

Best,
Blake


On Friday, 10 July 2026 at 06:24, Kaveh Ranjbar <kaveh=[e-mail]> wrote:

> Ekr, you will get no argument from me on the numbers. I publish the DNSSEC scorecard athttps://state-of-dnssec.whisper.security/ , so I am a critic of DNSSEC deployment before I am an advocate for it. That is exactly why I do not think second-level signing rates bear on this scheme.
> 
> The deployment unit here is not the agent, it is the operator's zone, signed once. An operator stands up one DNSSEC-signed zone and mints any number of identities as names under it. Our agents all live under a single signed agents.whisper.online, not one signed domain per agent. So the shape is not "most agents deploy DNSSEC first"; it is one operator signs one zone once, as part of the same deliberate act of standing up verifiable identity, and the unsigned 95% of .com is a population we ask to do nothing. Adoption at large is the wrong denominator: this is opt-in for parties provisioning specifically to be independently verifiable, not a migration of the existing web.
> 
> On "might as well use .well-known": for a web bot whose verifier already sits inside WebPKI, you are right, and I conceded exactly that to Ben, the DNS path earns little there. Where they are not equivalent is the verifier that is not in a WebPKI context, agent-to-agent, out of band of any TLS transaction. There, /.well-known over HTTPS reintroduces the WebPKI and web-endpoint dependency that the DANE record removes, so the two are not interchangeable. That verifier is who this is for, not the web bot.
> 
> So: a complement scoped to the non-web verifier, not a replacement for /.well-known, and nothing the unsigned web is asked to adopt. Thanks for pressing, it sharpened the scoping. The record-type and venue question belongs in DANCE, and I will carry it there.
> 
> 
> Kaveh
> 
> On Thu, Jul 09, 2026 08:17 PM, Eric Rescorla <[e-mail]> wrote:
> 
> > 
> > 
> > On Thu, Jul 9, 2026 at 12:08 PM Kaveh Ranjbar <[e-mail]> wrote:
> > 
> > > 
> > > On DNSSEC, and I want to be careful not to relitigate deployment, because I think adoption rate is the wrong axis for this design. "Limited deployment" measures how many resolvers validate, which is a verifier-side property, and here validation is opt-in per verifier.
> > 
> > 
> > I'm not talking about how many resolvers validate, but about how many domains actually have signed records (note that this is a distinct number from the number of domains signed by the parent). At present this is about 5% of .com and .net [0]. So what you're proposing is that most agents who want to participate need to deploy DNSSEC first. This is a lot more of a list than just standing up something on /.well-known.
> > 
> > > . The scheme never predicates on global adoption because it never asks anyone else to validate, only the party who chose to rely on it. For verifiers who do not want that dependency, the .well-known path is untouched.
> > 
> > 
> > In which case you might as well just use /.well-known.
> > 
> > -Ekr
> > 
> > [0] https://dl.acm.org/doi/abs/10.1145/3730567.3764428