Hi Tim, all, On Jun 7, 2024, at 01:11, Tim Wicinski <tjw.i...@gmail.com> wrote:
> On Wed, Jun 5, 2024 at 12:28 PM Paul Hoffman <paul.hoff...@icann.org> wrote: > >> Tim jumped the gun by about an hour: we just submitted the -05. It >> incorporates the suggested text from below; you can see the diff at: >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8109bis-05 > > I am guilty as charged. But our comment on we would like people to review > the changes. 3.3 DNSSEC with Priming Queries I know perfectly well what "the root NS RRset" is, but it seems like it could be made a little more clear with only a small change as "the apex NS RRset in the root zone", "root zone" being a well-defined term of art whereas "root" as adjective being a bit vague. More substantially, this section describes a series of vulnerabilities that would be mitigated by signing the ROOT-SERVERS.NET <http://root-servers.net/> zone. However, it does not mention that a validating resolver that received a rogue response from an imposter root server has the eventual opportunity to discard signed RRSets whose signatures do not validate; by not mentioning this there is perhaps some danger that a casual reader would infer a greater overall vulnerability resulting from an unsigned ROOT-SERVERS.NET <http://root-servers.net/> zone than in fact exists. Including signed RRSets from the ROOT-SERVERS.NET <http://root-servers.net/> zone in the priming response would result in larger responses, to which in the past there has been some sensitivity. Since a priming query with DO=1 definitely has EDNS(0) as an option this is not a show stopper, but if the previous sensitivites around all of this are no longer a concern I think it would make sense to say so explicitly when speculating about future signatures in that zone. The chain of trust from a root zone trust anchor through a signed delegation to NET and thence to ROOT-SERVERS.NET <http://root-servers.net/> would also deserve some scrutiny from the perspective of a priming response which is presumably often landing on an empty cache; the ability to validate those signatures requires queries to be sent to as-yet untrusted root servers. It seems odd not to mention this as something that would need work, given the depth of the other text that is included. The final paragraph makes a reference to a naming scheme, presumably referring to the names chosen for root servers (but that could be more clear). The RSSAC wrote quite a large document about this stuff and I certainly don't have all of their conclusions swapped in, but thanks to the late Bill Manning's flash of insight the current scheme features a high degree of name compression already and reducing the single label "ROOT-SERVERS.NET <http://root-servers.net/>" to something smaller is not going to substantially reduce the size of the priming response. It feels like part of the solution space here is to consider root-server names that live in the root zone and not in a child zone, which is a different consderation from the naming scheme. Mainly this paragraph reads like a throwaway comment that doesn't include enough depth to be useful. It should at least say something along the lines of "this is complicated". I realise that at the time of writing it is not before June 14. Happy to contribute text if other people think that in this particular case I am not completely insane. Joe _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
