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]
