And a quick addendum I meant to add in the earlier note -- for many of the newer security claims like the query redirection privacy exposure threat, that does require "strict" validation (as already pointed out on list by Ben Schwartz, and as already stated in the draft) - the draft currently supports both strict and opportunistic, and I would expect an implementation to offer a configurable knob for that. Operators that prioritize security vs raw performance would select the option appropriately.
Shumon. On Thu, Mar 20, 2025 at 5:42 AM Shumon Huque <shu...@gmail.com> wrote: > On Thu, Mar 20, 2025 at 12:28 AM Petr Špaček <pspa...@isc.org> wrote: > >> TL;DR >> In the light of an experiment outlined below, using a current version of >> Unbound, I'm not convinced the protocol in this draft is proven to work. >> Most importantly, it does not have running code for section 5.1, which >> is advertised as security measure in the discussions during this WGLC. >> >> Based on this observation, I claim draft version -09 is not suitable for >> publication as a Standards Track RFC. >> > > > Petr, > > I don't have time right now to review your lengthy investigation of the > Unbound implementation, and will defer to Willem to respond later. > > But let me make a few quick points: > > As far as I'm aware, Unbound has the "basic" revalidation feature that was > originally described in 2009 and 2010 in the resolver-side-mitigations > (Wijngaards) and res-improve (Vixie, Joffe, Neves) drafts. I'm sure they > will have a complete implementation once this doc is published. There have > also been other implementations in the field, but I'm not familiar with > them. > > A complete running code implementation is NOT a requirement for a document > to be initially published on the Standards Track (although per the IETF > motto, running code is always highly desirable). > > To quote RFC 2606, Section 4.1: > https://datatracker.ietf.org/doc/html/rfc2026#section-4.1 > > (I quickly scanned the many RFCs that "Update" 2606, but none appear to > have revised this section at all, and some re-confirm it). > > 4.1.1 Proposed Standard > > The entry-level maturity for the standards track is "Proposed > Standard". A specific action by the IESG is required to move a > specification onto the standards track at the "Proposed Standard" > level. > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation. > > [...] > > Shumon. > >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
