Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

[Bob Harold <[e-mail]>]

On Fri, Oct 6, 2023 at 8:54 AM Shumon Huque <[e-mail]> wrote:

> On Fri, Oct 6, 2023 at 8:20 AM Bob Harold <[e-mail]> wrote:
>
>>
>> On Thu, Oct 5, 2023 at 6:16 PM Paul Hoffman <[e-mail]>
>> wrote:
>>
>>> On Sep 14, 2023, at 18:46, Tim Wicinski <[e-mail]> wrote:
>>>
>>> > We chairs heard back from the authors and we're pulling this working
>>> group last call.
>>>
>>> We have turned in a -01 that addresses the initial comments in the WG
>>> Last Call that the document had obvious labeled holes in it. One of those
>>> holes had an old label on it, but the others needed filling, and we have
>>> done that now. Whenever the chairs have another slot to start a WG Last
>>> Call, we think this is now ready for it.
>>>
>>> --Paul Hoffman
>>>
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc8109bis-01
>>
>> 3.3. DNSSEC with Priming Queries
>>
>> The second paragraph confused me:
>>
>> "A machine-in-the-middle attack on the priming query could direct a
>> resolver to a rogue root name server. Note, however, that a validating
>> resolver will not accept responses from rogue root servers if they are
>> different from the real responses because the resolver has a trust anchor
>> for the root and the answers from the root are signed. Thus, if there is a
>> machine-in-the-middle attack on the priming query, the results for a
>> validating resolver could be a denial of service, or the attacker seeing
>> queries while returning good answers, but not the resolver's accepting the
>> bad responses."
>>
>> I took me a while to understand, but something like this is what I think
>> it means, a little more clearly to me:
>>
>> A rogue server could return the proper NS RRset and signature, but fake A
>> and AAAA records, since they are not signed, which would effectively block
>> access to the root zone.  But when a request is made for other records in
>> the root zone (like delegation NS records for a TLD, its normal role in DNS
>> resolution), those records are DNSSEC signed and can be validated, so a
>> rogue server can only block service, not give wrong answers that pass
>> validation.
>>
>> Could something like that be included?
>>
>
> I don't think that's correct.
>
> A priming query is for the NS RRset at the root zone. Root servers will
> authoritatively answer that and return a signed root NS RRset, which can be
> authenticated by resolvers. The glue records however are unsigned and could
> be faked, so resolvers could still be directed to communicate with rogue
> servers. But they could detect that attack after the fact, by examining the
> subsequent responses from the rogue servers, and see if the parts in those
> responses that should be signed are actually signed correctly.
>
> Note that delegation NS records in a referral response are NOT signed
> (they are not authoritative data). What is signed is either a DS record
> (set) proving secure delegation to a signed TLD, or an NSEC record that
> proves insecure delegation to an unsigned TLD.
>
> I agree that the wording could be improved. I had trouble understanding
> that paragraph too.
>
> Shumon.
>
>
Thanks for explaining that.

-- 
Bob Harold