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]
