Ben, Bob: Thanks for your valuable feedback. Here are my responses to comments by Ben and Bob:
Response to Ben * Make it work with KEYTRANS. Key Transparency makes this much more powerful by reducing the required trust in the host. * Agreed. DKA addresses collection, verification and distribution of keys; KEYTRANS addresses transparency and audibility of the provider’s behavior. So, in deployment, DKA will benefit from the added trust of KEYTRANS. * But, as protocols, they are orthogonal, non-overlapping, and complementary. * That said, a future version of the document will address the integration of DKA with KEYTRANS in deployment. * 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. * Yes, that sounds like the right thing to do. TXT should be the canonical DKA designation record. * 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. * Just a point of clarification: DNSSEC is not mandatory in the draft; it is recommended. * A .well-known URL is an interesting suggestion, but I do not think it is the right architectural mechanism for DKA designation. The DKA is a domain-level infrastructure function: it identifies the service that is authoritative for public keys associated with email-address identifiers under that domain. That kind of designation belongs at the domain/DNS layer, not in an application-level HTTP resource. * 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. * 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. I think this misunderstands the proposal. * DKA is NOT an “email encryption” proposal. It is a framework for associating public-keys with email-addresses functioning as identifiers. * Email addresses are already widely used beyond email delivery: they function as identifiers across login, account recovery, commerce, government, healthcare, enterprise, and other Internet systems. DKA takes that already-deployed identifier namespace and gives it cryptographic utility. [When one uses Gmail ID to log into Facebook, the Gmail ID functions as a human-readable and globally unique user ID, not as an email endpoint, though the latter is useful for account reset functions]. * The reason the draft is scoped to email-address identifiers is not accidental. Email addresses have two properties that make the association of public keys with email addresses useful and tractable: * They already form a globally deployed, domain-scoped, widely used, human-readable namespace. * Control of an email address can be verified using existing Internet mechanisms, in particular mailbox control and DKIM. * 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]<mailto:[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]<mailto:[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/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-swaminathan-dka-framework/__;!!Bt8RZUm9aw!6E6r7m2UcDjNUlDJn5f-_2YbNY_dnb0DMZYPp7rQQyFjQaOp_ulMOscGaXcvQSDlKeb7ENzrgBtIoDA0fBMD$> 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<https://urldefense.com/v3/__https://keyzero.org/__;!!Bt8RZUm9aw!6E6r7m2UcDjNUlDJn5f-_2YbNY_dnb0DMZYPp7rQQyFjQaOp_ulMOscGaXcvQSDlKeb7ENzrgBtIoOEMneTD$>. All comments appreciated. Kishore Swaminathan _______________________________________________ DNSOP mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ art mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
