Hi Joe, Comments inline.
Op 07-06-2024 om 10:33 schreef jab...@strandkip.nl:
Unfortunately not. I would say that have the potential to be mitigated by a signed root-servers.net one, but at the time of writing, a signed root-servers.net zone would have impact. (see: https://www.icann.org/en/system/files/files/reduced-risk-redirected-query-traffic-signed-root-name-server-data-22may24-en.pdf )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-05I 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.
Agree, we could mention the opportunity. But it requires changes in resolver software behavior (see again the above quoted report).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.
Signed root server addresses included with the priming response cannot help. A resolver cannot determine whether those are authoritatively present in the root zone or not (and if they are not they can be included without signatures, so an adversary can always replace signed root server addresses with spoofed addresses without signatures; see section "DNSSEC signed root server addresses in the priming response" in the above quoted report: https://www.icann.org/en/system/files/files/reduced-risk-redirected-query-traffic-signed-root-name-server-data-22may24-en.pdf#h.tb7mwc7hrt18 )Including signed RRSets from the ROOT-SERVERS.NET<http://root-servers.net/> zone in the priming response would result in larger responses,
Agree, this needs work. I am working on text within the delegation revalidation draft that explicitly addresses this. Perhaps it should be referenced from here (but I steel need to update the text and submit the new version).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.
I assume you are referring to RSSAC028. Note that we also did an extensive evaluation of those naming schemes and have written that all down in another report: https://www.icann.org/en/system/files/files/rssac028-implementation-study-report-27sep23-en.pdf
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".
Unfortunately, as I mentioned above, signed root server addresses included with the priming response cannot help. However, revalidating the root server addresses would help, so I do think alternative text for the last paragraph is needed. How about this:
"DNSSEC validation of the priming query is valuable when root-servers.net zone will be DNSSEC signed *and* resolvers revalidate the root server addresses, by following up with direct A and AAAA queries for the names of the root NS RRset"
-- Willem
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 todnsop-le...@ietf.org
OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
