Re: [dnsext] Clarifying the mandatory algorithm rules

[Brian Dickson <[e-mail]>]

On Fri, Dec 10, 2010 at 5:08 AM, Matthijs Mekking <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/09/2010 04:47 PM, Edward Lewis wrote:
>> At 16:19 +0100 12/9/10, Matthijs Mekking wrote:
>>
>> So, so what if I say DNSSEC is not there to protect the zone operator.
>> Why does that mean that MUST is wrong?  The rationale is that no matter
>> what you do, local policy is going to be followed. Local policy is going
>> to prefer quick resolution of the query. Requiring DNSSEC to do extra or
>> extraneous work is not constructive - by that I mean, once you've gotten
>> a chain of trust why keep trying to find faults?  DNSSEC is not designed
>> to be the last line of defense.
>
> The additional work is there for algorithm compromise protection. And as
> I argued before, yes it is local policy to let the validator fallback to
> "One Signature Is Enough". But it is kind of insane to me to have a
> local policy that says 'allow badly signed zones'.

I think there are two issues here.

One is, whether all signatures are of equal importance.

I'd say, SEP-related signatures (DS signatures, DNSKEY signatures) are much
more critical, and should receive maximum protection, performance
notwithstanding.

I'd also say,  the fewer labels there are, the more important, for the
same or similar reasoning.
The higher up the food chain, the bigger the target painted on the zone.

The second is, that accepting just *any* (valid) signature, means the
following consequence occurs:
If *I* choose which signature to check, the bad guy trying to spoof
the signature risks detection.
If the bad guy chooses (by ensuring only his spoofed signature will
validate, by stripping others
or replacing others with bad signatures), he can guarantee avoiding detection.

Even adding a randomization among known algorithms, and insisting that
a match must occur for that,
adds the probability of detection, without adding to the crypto burden
of the validator.

And something else that bothers me:

If $implementation does detect a validation failure, which in theory should not
be possible, what about signaling this to the zone owner/operator?

The zone itself might not be broken, but merely be under attack from
an off-axis attacker.
Or, the zone might be broken. There is no way for the validator to
know, and no way for
the owner/operator to currently discover this (automatically).

Should this be addressed? If so, how?

Brian