Hi Tirumal On Thu, Mar 19, 2026 at 03:14:23PM +0530, tirumal reddy wrote: > 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.
Thank you for stating this, because from your previous email, I really thought you didn't like the dissenting opinion. :) > > > > 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. I follow why you've added sub-error. It could have been flattened into EDE INFO-CODE as described in a previous email in this thread. This is not database normalization where there's a ton of data and the schema has to be strictly normalized into different entities to avoid duplication. A 3rd level result code could have been avoided for implementation simplicity, because we are not going to have many EDE INFO-CODEs overall. There's a lot of unused space in the EDE registry (49118 unused code points as of now, which if were allocated at the rate of one a day would take 135 years to consume). The same INFO-CODEs could then be used in plain RFC 8914 EDE too. > > > > 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. This is not the last-call list. It is dnsop, and we can provide opinions whether it is in last-call or even after it's published as RFC. I have never emailed the last-call list to block any draft. My comments here are not out of some desire to derail this work. I've been asking about the premise of this work because what's in the abstract and introduction can be satisfied by RFC 8914. You and Lars have mentioned in this thread that this special magic is necessary to achieve something browser implementors desire, but I didn't get that by reading the abstract and introduction (purpose of this draft). I understand that this draft has been in LC before, returned to dnsop, and it must be a long and frustrating process for you. My email may have come later than you would like to see, and against hard work that you've put in, but my points are the same as before. BTW I'm not entirely against this. From a different perspective of a commercial DNS implementation, a draft like this with bells and whistles is favourable because it increases the barrier to entry. Having this extra protocol implemented makes a deeper moat and it's a few hundred lines of code over the extensive EDE implementation we already have. The camel is fine with this draft in that regard. I sent the review with my opinion after reading Benno's email. > > 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. That's fair, I should have pursued this. But my dnsop involvement is a patchy, and now and then unfortunately due to other work commitment. I have reviewed this a couple of times when I could. > > 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 Tirumal, the purpose of your draft is this. It shouldn't be a footnote. What is the premise? "This draft communicates contact and DNS filtering information over secure transport to web browsers to show in dialogs/pages in a secure UI context, which RFC 8914 is incapable of conveying." State this in the introduction so that it's clear why this draft is necessary over what's already there. Would you like me to write some sentences that you can edit and add to the introduction? Mukund _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
