On Thu, 19 Mar 2026 at 11:05, Mukund Sivaraman <[email protected]> wrote:
> Hi Tirumal > > On Thu, Mar 19, 2026 at 10:26:59AM +0530, tirumal reddy wrote: > > Unlike a webpage served over HTTPS which has transport security and > server > > authentication, a DNS response carrying arbitrary free-form text does not > > have the same guarantees, making structured and validated content > > essential. For instance, a free-form EXTRA-TEXT string containing URLs or > > contact information can be manipulated by an on-path attacker to redirect > > end-users to malicious sites, which is precisely the attack the draft > > addresses. > > On-path attackers may modify the JSON too unless transport security is > used. I am aware this draft requires transport security, but the > alternative can also be as simple as requiring transport security if a > browser wished to display RFC 8914 extra-text to a user. > Transport security is a channel protection mechanism and does not constrain the content carried. RFC8914 explicitly says EXTRA-TEXT should be restricted to diagnostic use only. This draft addresses that gap by imposing explicit client security policy requirements on the display of the "c", "o", and "j" Fields, which transport security alone cannot provide. > > > Another example could be, RFC8914 EXTRA-TEXT has no language tag, > > determining the language of a short string is challenging, making > > translation or locale-appropriate handling unreliable; this draft solves > > this by tagging the error response with the language, enabling clients to > > handle it appropriately. > > > > WGLC is intended to identify technical issues with the current > > specification, not re-open the question of whether the work should exist, > > the WG already reached consensus on that at adoption. > > > > This draft has a history of several years where the need for it was > > discussed and agreed upon at adoption, and it has continuously evolved to > > address various issues including, threats and deployability. If you are > > still not convinced of the need for this draft, I suggest reviewing the > > history of this draft and the extensive discussions on the mailing list. > > By this, you're saying it's not necessary to discuss the basis for this > draft anymore or ask to have it explained clearly in the introduction. > > > Thank you for clarifying, we appreciate the engagement. If you have specific text proposals to improve the current draft, we are happy to consider them. > I was one of the early > reviewers of this draft and I pointed out some of these concerns early > on. My previous emails dated 2023-06-27 and 2025-10-31 on the topic of > the sub-error registry did not get responses. > The rationale is already explained in the draft: sub-error codes apply across multiple EDE codes (e.g., Blocked, Blocked by Upstream DNS Server), so allocating INFO-CODEs would require replicating each sub-error for every applicable EDE code, which is unnecessary. > > If what this offers over RFC 8914 is a contact field and a requirement > of transport security, a 8914 bis section requiring transport security > for browsers, and an EDNS option just for contact information that > complemented RFC 8914 would have been simpler. What would you like us to do with this comment, go write an RFC8914bis ? This is WGLC and we would prefer to focus on comments specific to the current specification. > > My conclusion in the email dated 2023-06-27 is similar to the email I > wrote yesterday. > Med had responded to your mail and the thread concluded at that point. > > You could improve this work by describing in the introduction what the > benefits of this draft are over RFC 8914, i.e., what is it that can be > done with this draft that cannot be done with RFC 8914. For example Lars > mentioned in a different email in this thread that the information is > shown in a separate security context where EXTRA-TEXT cannot be > used. You mention earlier in your email that this contact information > cannot be manipulated (due to transport security). Mention that this > draft exists for these reasons in the introduction. > It is already discussed in the draft, see https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-18.html#section-10 -Tiru > > Mukund >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
