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

To quote Benno:

> We have placed the author under moderation to prevent messages generated entirely by an LLM from appearing on the mailing list.  This in no way implies that we wish to moderate the topic, but we do want to make it clear that people should check their messages before posting them to the mailing list.

This now also applies to the author of the LLM-generated text below.

Ondrej
--
Ondřej Surý (He/Him)
[email protected]

A gentle nudge is always appreciated if I take a little longer to reply.

> On 11. 6. 2026, at 1:35, S Kishore <[email protected]> wrote:
> 
> Ben - Many thanks for your engagement with the DKA proposal and thoughtful comments and suggestions. My answers to your concerns/suggestions below. 
> 
> 
> Ben >>
> 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.
> 
> Answer: 
> Thank you for raising this point. DNS security is an important consideration for the DKA framework, and the draft recommends DNSSEC (SHOULD) rather than mandating it (MUST) for considered reasons.
> DKA is no more vulnerable than other DNS-designated domain services. The same attack (poisoning a DNS record to redirect a domain service to an attacker-controlled server) applies to MX records, SRV records, DMARC policy records, and many other DNS-designated services. An attacker who can poison a domain's DKA TXT record can equally poison its MX record and redirect all inbound email to an attacker-controlled mail server, which is strictly more damaging. Yet MX records do not mandate DNSSEC, and the Internet's email infrastructure operates on the same SHOULD-level DNSSEC recommendation. Mandating DNSSEC for DKA alone would hold it to a higher standard than the mail system whose identifiers it serves.  
> A DNS-level DKA attack is a disruption vector, not a precision credential-theft vector. DNS redirection of a DKA affects all identifiers under the domain simultaneously. An attacker who wants to target a single user (say, [email protected]) by redirecting the DKA must redirect it for the entire domain. Even if the attacker's DKA faithfully mirrors the real DKA's responses for everyone except the target, the attack creates multiple independent detection signals:
>     • The DNS record itself has changed, which is visible to domain administrators and DNS monitoring tools.
>     • The real DKA's traffic drops, triggering operational alerts.
>     • The attacker's DKA cannot send valid DKIM-signed registration or confirmation emails as register@<dka-hostname>, because it does not control the real DKA domain's DKIM private keys. Any user who interacts with the registration protocol will observe DKIM validation failures or unexpected sender domains.
>     • A DKA can monitor its own DNS designation and detect unauthorized changes.
> This contrasts with per-key attacks (such as poisoning a single key on a PGP key server), where a high-value target can be compromised without observable impact on other users. A DNS-level DKA attack has too broad a blast radius for surgical use.
> DKA redirection alone does not give the attacker access to encrypted content. The DKA distributes public keys; it does not route messages. An attacker who redirects the DKA and serves a fraudulent public key for [email protected] gains a decryption capability (possession of the corresponding private key) but does not gain access to the ciphertext. Messages encrypted with the fraudulent key are still routed to Alice's legitimate mailbox or to other messaging systems, which the attacker does not control. Alice observes a decryption failure, itself a detection signal, and the attacker never sees the ciphertext. To actually read Alice's messages, the attacker would need to independently compromise the message delivery infrastructure and message client authentication which are separate attacks requiring separate capabilities.
> The impact is forward-only. A DKA redirection does not compromise previously encrypted messages or previously verified signatures. Only new operations that consume the fraudulent key during the attack window are affected.
> Recovery can be quick and does not require administrative or CA intervention. Because mailbox control is the lifecycle trust anchor in the DKA framework, once the DNS compromise is remedied and the legitimate DKA is restored, users can rotate their keys through the standard DKA registration and key rotation processes without intervention by administrators or certificate authorities. There are no revocation lists to update. 
> Mandating DNSSEC would create a deployment barrier. DNSSEC penetration remains low across most TLDs. Requiring DNSSEC as a prerequisite for DKA participation would gate adoption on an infrastructure upgrade that many domains have not yet performed, undermining the framework's incremental deployment design principle. The SHOULD-level recommendation communicates that DNSSEC is the right practice without preventing participation by domains that have not yet deployed it.
> In summary: the DKA framework's exposure to DNS-level attacks is real but bounded. The attack is not system-wide (limiting attack impact) but domain-wide (increasing detection probability), does not by itself yield access to encrypted content (requiring independent compromise of message delivery), affects only forward operations, and is recoverable without administrative intervention. These properties, combined with the practical deployment reality of DNSSEC adoption, support SHOULD rather than MUST.
> 
> Ben >>
> 
> 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.
> 
> Answer: 
> 
> The security of HTTPS-authenticated designation depends on the integrity of certificate issuance, which for domain-validated certificates (the vast majority, issued via ACME) depends on DNS. An attacker with the DNS control needed to poison a DKA TXT record can also satisfy an ACME HTTP-01 or DNS-01 challenge and obtain a valid certificate for the target domain. The .well-known approach therefore does not eliminate the DNS security dependency; it routes it through the CA's domain-validation process, which itself relies on DNS. Both approaches ultimately require DNS integrity for their security guarantees, and DNSSEC provides that integrity at the appropriate layer.
> 
> That said, you are correct that HTTPS with TLS is more secure against a simple DNS redirect. 
> 
> Ben >>
> 
> 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.
> 
> Answer: 
>     • This is a practical and well-observed point and thanks for pointing this out. For email providers that already perform key management on behalf of their users (whether through S/MIME certificate infrastructure, enterprise key management, or internal provisioning systems), the email-based registration protocol defined in the DKA specification would be unnecessarily indirect. Such providers could populate their DKA directly through internal processes, and this is indeed likely to be more reliable and operationally simpler than routing through the in-band email mechanism.
>     • The DKA specification as written does not prevent this. The email-based registration protocol is the standardized, interoperable mechanism that any registrant can use with any conforming DKA, but nothing in the specification prohibits a DKA operator from also accepting key submissions through additional channels. The DKA is the domain's service, and the domain operator may populate it through whatever internal processes are appropriate to their environment.
>     • The key architectural provision for this is the “verification_methods" field in the Key Lookup Response. This field reports what verification was performed when the key was registered, and consuming applications use it to make trust decisions. When a key is provisioned through an internal arrangement rather than through the email-based protocol, neither mailbox-control nor dkim-validation (the two verification methods defined in the current specification) was performed in the protocol-defined sense. The verification_methods field must accurately state what verification was actually performed, regardless of the submission channel.
>     • This is where the IANA verification methods registry becomes important. The registry, defined in the specification with a Specification Required policy, is the extension point for exactly this kind of use case. A future companion specification could define additional verification method identifiers such as ca-certified (for keys backed by a CA certificate chain), operator-provisioned (for keys published by the domain operator through internal processes), or other identifiers appropriate to specific provisioning models. An S/MIME domain, for example, could publish CA-certified keys through its DKA and report ca-certified in the verification methods, giving consuming applications the information they need to apply their own trust policies.
>     • This design is intentional: the DKA framework decouples key distribution from the trust model. Any trust model (mailbox control, CA certification, enterprise directory validation, or future mechanisms) can feed keys into the DKA, and the verification_methods field makes the provenance transparent to consumers. The DKA serves as a uniform discovery and distribution layer; the verification methods registry communicates how each key was verified; and consuming applications decide what level of verification is sufficient for their security requirements.
>     • I will add a brief note to the specification acknowledging that DKA operators may accept key submissions through mechanisms beyond the email-based registration protocol, with the requirement that the verification_methods field accurately reflects the verification actually performed. The details of specific alternative provisioning mechanisms and their corresponding verification method identifiers would be defined in future companion specifications.
> ..Kishore
> 
> From: Ben Schwartz <[email protected]>
> Date: Monday, June 8, 2026 at 4:35 PM
> To: S Kishore <[email protected]>
> Cc: Bob Traverz <[email protected]>, Art Area <[email protected]>, [email protected] <[email protected]>
> Subject: Re: [art] Re: [DNSOP] DNS-designated Public Key Authorities (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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.com%2F.well-known%2Fdomain-key-authority&data=05%7C02%7C%7Cf82351a4918540a29ce108dec5a5cec7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639165513078436352%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ge8IspbfZ1g3%2BzIPXRTvMenwrLenMcdkBSRekaL87AI%3D&reserved=0" 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-swaminathan-dka-framework%2F&data=05%7C02%7C%7Cf82351a4918540a29ce108dec5a5cec7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639165513078470505%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=b4dDW65QTMBCDcPwksf8UAbO8WLjIE47Rfvc%2FnLox%2Fo%3D&reserved=0
> >
> >
> > 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeyzero.org%2F&data=05%7C02%7C%7Cf82351a4918540a29ce108dec5a5cec7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639165513078490419%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SGDg5r%2FobceYKrYLyrZcwIDtsw1js8KxWL4XntwatXk%3D&reserved=0.
> >
> > 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]

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]