Re: [dnsext] Clarifying the mandatory algorithm rules

[Matthijs Mekking <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ed,

On 12/09/2010 02:44 PM, Edward Lewis wrote:
> At 10:59 +0100 12/9/10, Matthijs Mekking wrote:
> 
>> Although this is local policy, I also think it is bad policy for a
>> validator to allow algorithm compromises and badly signed zones. Thus, I
>> would go for a MUST here.
> 
> The reason it can't be a MUST is that a zone may be signed with
> algorithm 42.  If a resolver does not know algorithm 42, how can it
> determine whether the signature using algorithm 42 is valid or invalid?

Of course, the statement is still only valid for algorithms that the
resolver knows of. So it can still be a MUST.

> Let's say a zone is signed by algorithms 5 and 7.  (A choice made
> specifically because the two algorithms have the same mathematical
> properties. ;))  What would you think if you received a set of data and
> signatures and discovered that the algorithm 5 signature validated the
> signature but the algorithm 7 signature did not.  What if the reason
> were cryptographic?  What if the reason was that the algorithm 7
> signature had simply expired (with or without NTP running)?  What if the
> reason was that the algorithm 7 signature had not yet entered its
> effectivity period?

When following the guidelines for "Check the Algorithms" with MUST, if
both algorithms are present in the DS RRset, and the algorithm 7
signature did not validate, the security status would be set to bogus.
The reason why the signature failed does not matter.

> If you can establish a chain of trust to a data set, why withhold it
> from the application requesting it in case you find that there is also a
> signature that fails?

Because the zone operator specifically wants to be protected against
algorithm compromises and does that by listing more than one algorithm
in the DS RRset.

> Assume a set of data has a legitimate signature in algorithm 5 that
> validates and you see an algorithm 7 signature that does not validate? 
> What if the cause of this was that an attacker wanted to perform a
> Denial of Service by applying an intentionally bad signature (which is
> trivial to do) to guarantee a failed chain of trust?  It's like allowing
> someone to say "don't trust the authorities, I'll insert some doubt so
> you won't use the information."

A Denial of Service is always easy. Stripping the signature is just as
easy to perform a DoS attack.


Best regards,

Matthijs


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNAPOFAAoJEA8yVCPsQCW5Os8H/jcfeckDNRo6+ECgPXHdcBY5
FbR/6dke8wCmFcay9cLNE17UsbKywhI8CgB82bZC5gsVLmmx3NQQkRWfMcpp7eWa
xJh4QAZ6MRqv83hBhlpfPi3byvqhRRDDC2NAyfSEWSQ45iWOo9yHsmcFBCXs2Rjj
wCLpQi+CGR76oeYcWoyOBW14FAKZv3n0QRf4jKeqJjB3hAoUU2v4GFGRITSQVTHD
XTbUY2b26jzUuupzXXntvvJ0cO4jJlT/skJi4bQ/vThhvlBG0hk19HqLV/NAEP9f
kLqi1cASRX5gue80P8pBHujVys1SGsQG6bgDh9ObntqKPNMoKjoICa77Prc8XDY=
=EGBr
-----END PGP SIGNATURE-----