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

[Kaveh Ranjbar <[e-mail]>]

Ekr, you will get no argument from me on the numbers. I publish the DNSSEC
scorecard at
https://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
>