Subject: Re: [DNSOP] New Version Notification for draft-ietf-dnsop-nsec3-guidance-03.txt

From: Petr Špaček <[email-masked]>
Date: Wed, 2 Mar 2022 12:33:48 +0100

On 28. 02. 22 18:11, Viktor Dukhovni wrote:
> On Mon, Feb 28, 2022 at 03:43:59PM +0100, Petr Špaček wrote:
> 
>> Keep this:
>>   >>> 3.2.  Recommendation for validating resolvers
>>   >>>     Note that a validating resolver MUST still validate the signature
>>   >>>     over the NSEC3 record to ensure the iteration count was not altered
>>   >>>     since record publication (see [RFC5155] section 10.3).
>>
>> And here add this as continuation of the previous sentence?
>>
>> ... because the invalid signature might have additional implications.
>> E.g. EDE code, or insecure validation status if an implementation chose
>> to treat certain range of NSEC3 iteration values as DNSSEC-insecure etc.
>>
>> (modulo grammar fixes etc., of course)
>>
>> I think this makes the reason clear to everyone and also makes it
>> somewhat legal to ignore signature validation it IF "visible outcome"
>> does not change by doing so.
>>
>> What do you think?
> 
> I don't understand this comment, the reason for the signature check is
> that otherwise we get trivial downgrade attacks.  NSEC3 replies from
> a signed zone with an invalid signature MUST be treated as "bogus".
> 
> What did you have in mind?  What does "visible outcome" mean?

I'm just trying to rephrase what Vladimir already said.

His Knot Resolver has a single threshold and treats anything with 
iteration count value > XXX as bogus (by ignoring the NSEC RR with high 
iteration count), so why should he be validating the signature before 
declaring it SERVFAIL anyway?

There are only two options:
- Iteration count is too big and signature valid -> visible outcome = 
SERVFAIL
- Iteration count was modified and signature is invalid because of the 
modification -> visible outcome  = SERVFAIL

The only reason to validate would be to set EDE code, but if that is not 
being done by the implementation then "MUST validate" is unnecessary as 
it is busy work which does not change the visible outcome.

In the hypothetical scenario where the resolver had three ranges, "low 
enough to validate", "middle range to treat as insecure", "too high 
treat as SERVFAIL" then the MUST validate makes sense for the middle 
range where validity of the signature distinguishes between 
insecure/bogus states.

Does it make sense?

-- 
Petr Špaček