Apologies for long lag, I got sick right after IETF, despite being
remote :facepalm: I hope people who were on site are getting better!
Please see below.
On 3/19/25 23:42, Shumon Huque wrote:
On Thu, Mar 20, 2025 at 12:28 AM Petr Špaček <pspa...@isc.org
<mailto: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.
Shorter summary with pointers is now down below.
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 <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.
It seems to me the text above presumes lack of implementation and
experience, but that's not what we have. My previous message has several
pages of argumentation why the lack of implementation is not the only
problem we have.
To be precise, we currently have:
- Partial implementation in Unbound - for section 5.2 only (permissive
variant)
- Evidence of bad behavior/breakage caused by this Unbound's
implementation of permissive behavior, on the real world Internet, as
detailed in my previous message under heading Problem #1. See
https://mailarchive.ietf.org/arch/msg/dnsop/PsvrpRc8VGOnNvmbnmc74TcMjqA/
- Another implementation which reports problems with the proposed
protocol during this very WGLC:
https://mailarchive.ietf.org/arch/msg/dnsop/0tyRLxEHNRZnT8AzGVs2EhekfQE/
- Operational experience with bad child NS mentioned by me here:
https://mailarchive.ietf.org/arch/msg/dnsop/Xa2vROathQtVRBdQIuyhua57FmQ/
(paragraph right _before_ "The long term alternative is:")
Moreover several implementers said they are not going to implement it
for various reasons:
- https://mailarchive.ietf.org/arch/msg/dnsop/SzWj3XoE7NyExrsGKU5fBLTYnug/
- https://mailarchive.ietf.org/arch/msg/dnsop/SGHfXNom8Qn_fhr14c0ke9U9qYE/
- https://mailarchive.ietf.org/arch/msg/dnsop/_1-M-K6tn8zUIQ4HT-7YgDgRT7g/
Plus we have an alternative proposal mentioned here:
https://mailarchive.ietf.org/arch/msg/dnsop/Xa2vROathQtVRBdQIuyhua57FmQ/
At this point, publishing -09 as a 'Proposed Standard' seems like a bad
move to me. But I'm not an IETF lawyer. Perhaps it is permissible
process-wise. Whether it is a good idea is up to the chairs.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
