On Thu, 19 Mar 2026 at 16:39, Mukund Sivaraman <[email protected]> wrote:
> 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. > The layered approach provides richer and more precise error information. For example, "Blocked" means the server is unable to respond to the request because the domain is on a blocklist due to an internal security policy imposed by the operator of the server resolving or forwarding the query. Adding a sub-error code on top of this tells the client exactly why the domain was blocked, enabling better user-facing messages. So far we have not heard any arguments in favour of flat INFO-CODE allocation other than yours that outweigh the design rationale already documented in Section 4 of the draft. > > > > > > > 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. > For what it's worth, two DNS resolvers have already implemented this draft and browser vendors have shown interest; otherwise this draft would not have reached this stage. This is a strong signal that the industry sees value beyond what RFC 8914 provides. > > > > 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? > I will add text clarifying what this draft enables over RFC 8914. -Tiru > > Mukund >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
