[DNSOP] Re: [art] Re: DNS-designated Public Key Author ities (DKA)

All we need is a static JSON file at
./well-known/dka.json that says …
Even a pretty disorganized
operation should be able to manage that.

- A disorganized group is precisely what we don’t want managing a sensitive
and secure operation. Humans are usually the weakest chains in
cybersecurity and giving an infrastructure function to application
programmers (who are often temporary contract workers) does not increase
the security stance of an organization. With systems, at least you can
categorize your attack vectors and plan your defenses; without codified
processes, human processes are a much bigger security risk.

With respect to the DKA discussion, I’d run the “edge-case” test to test if
a proposed architecture makes sense. Does a domain, to have a DKA,
necessarily require a website or other HTTPS assets? If not, there is no
inherent dependency between a website and a DKA. Forcing a domain to have
an “A” record designating a Https resource just to run a .well-known URL
that delivers another endpoint is simply an end-run around the DNS. Feels
like a hack rather than a well-designed architecture.

Regards,

Bob Traverz

On Fri, Jun 26, 2026 at 9:13 AM Ben Schwartz <bemasc=
[email protected]> wrote:

> On Thu, Jun 25, 2026 at 2:57 PM John Levine <[email protected]> wrote:
> ...
> > At a lot of organizations the people who run the mail and the people who
> run the
> > website do not talk to each other. So if you want to publish key info for
> > [email protected] ... you would often be told to
> > forget it.
>
> Dynamic integration between the email account database and the web
> serving could be difficult, sure, but that's not what we're talking
> about here.  All we need is a static JSON file at
> ./well-known/dka.json that says {"dka-url":
> "https://dka-provider.example/"}.  Even a pretty disorganized
> operation should be able to manage that.
>
> ...
> > While an SMTP extension is a technical possibility, in practice, again
> forget it.  SMTP has
> > a VRFY command that you have probably never heard of which is intended
> to let you check if
> > a mail address exists.  Spammers discovered it about 30 years ago to
> harvest mail addresses,
> > and everyone turned it off.  A key server extension would be similarly
> unpopular.
>
> We are starting from the assumption that the SMTP server operator
> _wants_ to announce a key distribution server.  So why wouldn't they
> want to announce that server over SMTP?
>
> This approach doesn't require the key _lookup_ to occur over SMTP.
> Key lookup can (potentially) use a different server and a different
> protocol.
>
> > So I guess the mta-sts like hack is a possibility, but I would think
> hard about how you
> > are going to make it usable without also making it an attractive
> nuisance.
>
> Choosing a fixed subdomain is also possible I guess.  I don't see why
> it's preferable over .well-known though.
>
> --Ben
>
> _______________________________________________
> art 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]