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

On Sat, May 30, 2026 at 3:14 PM S Kishore <[email protected]> wrote:
...
> Just a point of clarification: DNSSEC is not mandatory in the draft; it is recommended.

Yes, but it needs to be mandatory in this design.  Otherwise, any
on-path attacker can replace the DKA TXT record with one that points
to the attacker's DKA, allowing them to impersonate all identities on
the victim domain.

...
> A .well-known pointer would also not eliminate the underlying DNS security dependency. A client still has to use DNS to reach the HTTPS origin serving that .well-known resource, so absent DNSSEC, both the DNS-based designation and the .well-known alternative remain vulnerable to DNS redirection at discovery time.

No, HTTPS is not vulnerable to "DNS redirection" of the client.  The
attacker first has to fool the Certificate Authority in order to get a
mis-issued certificate.

...
> Control of an email address can be verified using existing Internet mechanisms, in particular mailbox control and DKIM.

I think the draft should also note the possibility of the DKA and
email host publishing key assignments by private arrangement.  For
email providers who already perform key management on behalf of the
accounts on the domain, this seems likely to be more reliable than the
"in band" mechanism.

--Ben

>
> So, the DKA framework is an attempt to give the most widely used identifier on the Internet cryptographic utility, so the public keys can be used for message encryption (not just email, but any messaging protocol), signature verification, user authentication without shared secrets, even for associating an email-id with a cryptocurrency address. DKA itself is provides verified binding between an email address and selector-scoped public keys, staying application- and (cryptographic) algorithm-agnostic.
>
> Ben: I hope that addresses your concerns.
> Response to Bob
>
>  It appears that the DKAs collectively lead to a distributed PKI for email IDs anchored on domains and DNS. Although this is not a PKI in the RFC 5280 sense, mentioning this context would make the specification much more understandable.
>
> Yes, that is a helpful way to orient the reader. DKAs may be seen a PKI for email IDs, but only in a very loose sense, as it does not rely on certificate chains, CA hierarchies, or revocation mechanisms of traditional PKI models (a la RFC 5280).
>
> Normalization Rules: Before banning dot-removal or plus-tag stripping, I recommend checking the current practices of Gmail and Outlook. This will ensure your specification caters to the majority of email IDs.
>
> That’s a good practical suggestion, will check what providers do and try to incorporate.
>
> Only halfway through the document I realized that the DKAs need not be subdomains and need not even be part of the domain. Here your examples are misleading - at least one example should show the DKA as outside the domain.
>
> My bad, fair criticism. An example such as _dka.example.com. IN TXT "dka=dka.hosted-dka.net” will be added to make this clear.
>
> DKAs need a full mail server for both incoming and outgoing email and all the corresponding DNS setup. This should be mentioned in the Manageability Considerations.
>
> A DKA does not necessarily need to operate a “full mail server” in the broad product sense, but it does need an inbound mailbox for registration messages, outbound mail capability for verification and confirmation messages, and the associated DNS/mail configuration needed for reliable delivery. There are many lightweight mail servers that a DKA can use such as Maddy and Docker-mailserver, as well as mail server-services such as Mailgun and Sendgrid. But I agree that this should be addressed in the specification.
>
> DKAs are most likely cloud-sourced. What special privacy or security concerns rise from cloud-sourced DKAs?
>
> That DKAs most-likely will be cloud-sourced is a reasonable observation, and I agree that the specification must address any special security or privacy implications of this.
>
> Bob: I hope that addresses your concerns.
> Thanks for your comments,
> Kishore
>
>
>
>
> From: Bob Traverz <[email protected]>
> Date: Friday, May 29, 2026 at 8:33 PM
> To: Ben Schwartz <[email protected]>
> Cc: S Kishore <[email protected]>, Art Area <[email protected]>, [email protected] <[email protected]>
> Subject: Re: [art] Re: [DNSOP] DNS-designated Public Key Authorities (DKA)
>
>
> Ben >> Architecturally, I think the idea of a keyserver per domain seems reasonable, and discovery via DNS is plausible enough. However, I would suggest the following changes and additions to the draft:
>
> It appears that the DKAs collectively lead to a distributed PKI for email IDs anchored on domains and DNS. Although this is not a PKI in the RFC 5280 sense, mentioning this context would make the specification much more understandable.
>
> Ben>> Drop the HTTPS record mode.  "HTTPS" records are for improving the bootstrapping of HTTP connections, not for identifying affiliated services that happen to use HTTP.  Using a TXT record here may be ugly but at least it matches the common practice in email world (DKIM, SPF, etc.).  We can also define a new RR type.
>
> I agree. HTTPS is for connection specification, not identification or discovery. TXT always works. New RR type is a deadend.
>
> Other suggestions:
>
>   - Normalization Rules: Before banning dot-removal or plus-tag stripping, I recommend checking the current practices of Gmail and Outlook. This will ensure your specification caters to the majority of email IDs.
>   - Document Weaknesses: (a) Only halfway through the document I realized that the DKAs need not be subdomains and need not even be part of the domain. Here your examples are misleading - at least one example should show the DKA as outside the domain. (b) DKAs need a full mail server for both incoming and outgoing email and all the corresponding DNS setup. This should be mentioned in the Manageability Considerations. (c) Precisely because of (b), DKAs are most likely cloud-sourced. What special privacy or security concerns rise from cloud-sourced DKAs?
>   - Demo: Your demo only shows part of your specification (verification and lookup) but do not show your DNS setup. How are your demo domains and their DKAs setup at the DNS level?
>
> Good luck.
>
> Bob Traverz
>
>
>
>
> On Fri, May 29, 2026 at 3:19 PM Ben Schwartz <[email protected]> wrote:
>
> Architecturally, I think the idea of a keyserver per domain seems reasonable, and discovery via DNS is plausible enough.  However, I would want to see several changes in this draft:
>
> 1. Make it work with KEYTRANS.  Key Transparency makes this much more powerful by reducing the required trust in the host.
> 2. Drop the HTTPS record mode.  "HTTPS" records are for improving the bootstrapping of HTTP connections, not for identifying affiliated services that happen to use HTTP.  Using a TXT record here may be ugly but at least it matches the common practice in email world (DKIM, SPF, etc.).  We can also define a new RR type.
> 3. Note that DNSSEC is mandatory.  This is presumably for discovery of public encryption keys (not signing keys, which can be accompanied by a signature chain), so the required security level is very high.  Mandatory DNSSEC is very limiting, so you might want to support "https://example.com/.well-known/domain-key-authority" as an alternative that will often be easier to deploy.
> 4. Reduce the emphasis on email.  Email encryption has gone out of style, but there are other user@host identity systems where key distribution may be more attractive.
>
> --Ben
>
> On Fri, May 29, 2026 at 2:44 PM S Kishore <[email protected]> wrote:
>
> All:
>
> Greetings.
>
> Based on feedback, a new version of "Domain Key Authorities (DKA): DNS-Designated Public Key Distribution for Email-Address Identifiers” has been submitted.
>
> https://datatracker.ietf.org/doc/draft-swaminathan-dka-framework/
>
>
> Abstract: Email-addresses are widely used beyond email itself, and
> the Domain Key Authority (DKA) framework provides a DNS-anchored
> mechanism for discovering public keys associated with those identifiers. A
> domain uses DNS to designate an authoritative key service for email-address
> identifiers under that domain. Instead of storing per-user public keys in DNS,
> the domain publishes a lightweight DNS record (HTTPS and/or TXT) identifying the
> hostname of its Domain Key Authority (DKA), and clients retrieve
> selector-scoped public keys from the DKA over HTTPS. This design
> uses DNS for what it does well -- global discovery and delegation -- while
> moving per-identifier key storage and retrieval to infrastructure that
> scales independently of DNS. The result is a DNS-anchored, application-
> agnostic framework for discovering public keys associated with
> email-address identifiers. The current draft adds HTTPS DNS record and
> retains TXT records for backward compatibility, and provides a deterministic
> DKA discovery and key lookup procedure.
>
> The concept is not theoretical: an open-source implementation and a demo site exist at https://keyzero.org.
>
> All comments appreciated.
>
> Kishore Swaminathan
>
>
>
> _______________________________________________
> DNSOP mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
> _______________________________________________
> 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]