Ben > My preference would be to eliminate this TXT record from the design entirely. Instead, DKA discovery could proceed via HTTP .well-known on the email domain, in-band via new SMTP commands (with TLS authentication), or in many other ways that do not allow an attacker to intercept and replace users' keys with their own.
Answer: Consider the two alternatives: _dka.example.com TXT “dka=dka.example.com” vs. https:// example.com/.well_known/dka/ The former is a public delegation of authority to the DKA to manage keys for users. Anyone can all see that dka.example.com is the key server for example.com. Email addresses represent users, and users are not necessarily in a trusting relationship with their domains (not to mention government control over domains). A DNS delegation creates an arms-length governance relationship between the DKA and the domain. The DKAs can be outside the domain (address-wise and administration-wise), supervised by user groups, have an ombudsman, DKA code can be independently audited, or the DKA implemented by a neutral third party. The moment you put a DKA designation in a https URL, you don’t know what the URL serves whom. The trust is broken. You can pile up all the channel security you want with TLS, but the signal that that flows through the channel can be manipulated by the domain. It is no-longer an arms-length relationship. If you have followed the OpenPGP debates over the years, transparency of key discovery has always been a major theme. Further, it is architecturally and organizationally incoherent. A key server is an infrastructure-level service that can cater to different applications and protocols. Hiding a DNS discovery service inside an application-level HTTPS endpoint, with SMTP mixed in somehow, is an application-level hack, not an architecturally robust protocol that can evolve over time. Ben > Requiring DNSSEC would resolve this, but it is far from universally deployed. Answer: DNSSEC may be the architecturally right solution, but its adoption rate and resolver stats are not encouraging. Ben > In this specific case, relying on an insecurely resolved TXT record to locate the DKA server permits trivial targeted attacks of a kind that are well-known from the early WWW. Answer: See my previous email. The discovery mechanism must carry the trust signal but need not bear the entire burden of security. Secondary mechanisms—multi-factor verification by the RP, CA signatures etc. can carry some or all of the security burden. (TLS being a very visible example of this). In fact, my recent work involves a Domain Trust Anchor: a single DNSSEC domain for the whole DKA framework that holds signing credentials of individual DKAs, and DKAs sign their payloads which the RPs can verify against these signing credentials. My point is: the discovery step should not become a single point of failure for the entire DKA security model. We must design for defense in depth. Ben > Pushing important decisions about trust levels out to the relying parties does not work well in practice. Answer: Do you have any specific examples or case studies? Because IETF stance seems to be the exact opposite. RFC 6024 codifies it as “Trust anchors have only local significance.” DKA philosophy reflects this IETF stance: be honest about your security vulnerabilities and report your verification methods to RPs. Let them make their own decision consistent with their local policy, as they know their security requirements better than the DKA. Ben > My preference would be to eliminate this TXT record from the design entirely. Answer: I am not in love with TXT records, but they have evolved to have no semantics, the semantics coming from underlying protocol. In that sense, I prefer TXT, but I think there should be a DNS record for this “arms-length” delegation of authority. MX is the closest we have. Maybe, if DKA goes somewhere, it should have its own record type. ..Kishore From: Ben Schwartz <[email protected]> Date: Monday, June 22, 2026 at 11:02 AM To: S Kishore <[email protected]> Cc: Art Area <[email protected]>, [email protected] <[email protected]> Subject: Re: [art] Re: [DNSOP] DNS-designated Public Key Authorities (DKA) On Sun, Jun 21, 2026 at 7:09 PM S Kishore <[email protected]> wrote: > Regarding the LLM: I did not know there was a policy saying that AI-assisted > messages should say so. To be clear, those recommendations are only my own, not the IETF's. > Let's step back a bit and ask what a relying party needs from a key > distribution framework. An RP needs two things: know where to find a key for > an identifier, and what basis it has for trusting that key for a given use > case? I understand the idea of flexibility here, but I think it is unwise. In the history of key distribution, I see a clear lesson that simplicity is essential for security. Pushing important decisions about trust levels out to the relying parties does not work well in practice. A high, clear, uniform threshold should be our goal for security. In this specific case, relying on an insecurely resolved TXT record to locate the DKA server permits trivial targeted attacks of a kind that are well-known from the early WWW. In my view, this weakness largely invalidates the security value of the proposal. Requiring DNSSEC would resolve this, but it is far from universally deployed. Additionally, clients often use DNS resolution APIs that do not clearly indicate whether DNSSEC was used, and complex questions arise when DNSSEC validation is performed externally by a recursive resolver. My preference would be to eliminate this TXT record from the design entirely. Instead, DKA discovery could proceed via HTTP .well-known on the email domain, in-band via new SMTP commands (with TLS authentication), or in many other ways that do not allow an attacker to intercept and replace users' keys with their own. --Ben
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
