[DNSOP] Re: [Ext] [DNSOP]Requesting final comments on draft-ietf-dnsop-rfc8109bis

[Willem Toorop <[e-mail]>]

Hi Joe,

Comments inline.

Op 07-06-2024 om 10:33 schreef [e-mail]:
> Hi Tim, all,
>
> On Jun 7, 2024, at 01:11, Tim Wicinski<[e-mail]>  wrote:
>
>> On Wed, Jun 5, 2024 at 12:28 PM Paul Hoffman<[e-mail]>  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.
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 
)
> 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.
Agree, we could mention the opportunity. But it requires changes in 
resolver software behavior (see again the above quoted report).
> Including signed RRSets from the ROOT-SERVERS.NET<http://root-servers.net/>  zone in the priming response would result in larger responses,
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 
)
> 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.
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).
> 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 [e-mail]
> To unsubscribe send an email [e-mail]