Re: [dnsext] Clarifying the mandatory algorithm rules

["W.C.A. Wijngaards" <[e-mail]>]

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

Hi Mark,

On 11/19/2010 03:18 PM, Mark Andrews wrote:
> Except the validator is not supposed to enforce it.  The point of
> the rule, for the signer, was to ensure that there would be *a*
> signature to validate with.

Right, that is the confusion.

>> Let me try to understand this and then respond.  You talk about having
>> to prepublish signatures before the keys are published.
>>
>> This is necessary with the current rules today for algorithm-support
>> reasons.  It does not go away if unbound has less strict checking.  The
>> affected servers could be bind, unbound or other implementations.
> 
> No it isn't necessary.
>
> I start out with algorithm A in DS and DNSKEY.  The DNSKEY has a
> TTL of 600.  I have a TXT record with a TTL of 600 which is fetch
> 300 seconds after the DNSKEY record is fetched.  I add a DNSKEY
> with algorithm B and re-sign the entire zone with A+B meeting the
> MUST.  301 second later a downstream validating client asks for the
> TXT record.  The client get a DNSKEY RRset with A+B and a TXT with
> A signatures.  This will validate as secure by a validator that
> supports A only.  This will validate as insecure by a validator
> that supports B only as there is no secure path from the parent to
> the child.  It will validate as secure by a validator that supports
> A+B.

Let me explain why I thought it was necessary.  The RFC links the
algorithms in the DS to the algorithms in the DNSKEY.  And the RFC links
the algorithms in the DNSKEY to the algorithms over the data.
Therefore, I did not think it was allowed to link the algorithms in the
DS to the algorithms over the data.  And that you had to check if
algorithms (and thus their signatures) were missing.

If you pick the algorithms from the DNSKEY to see if signatures over
data are missing, then in the above example, a validator that supports
A+B has to mark the answer bogus.

(I happily note as an aside, you can take the subset of algorithms that
is also published in the DS set and do strict-checks with that; this has
safe communication from the parent and more lenient algorithm rollover).

> Only when you start enforcing that the TXT and DNSKEY records have
> to have matching algorithms in the validator does this break despite
> the signer meeting the MUST.

Another source for this is RFC4641 algorithm rollover (with prepublish
of signatures before key).  I am a bit hazy why the 4641 (and -bis)
documents specify algorithm rollovers with signature introduction, if
this was not necessary; the editors and reviewers had similar confusion?
 I certainly looked at them to make sure they worked when I wrote the
algorithm code.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzmn78ACgkQkDLqNwOhpPgVqwCgpzI1URZLi6F4EyDpvwdwrXBH
mwAAn2Dr8o90brU8dPkcA+mXr8IahkmU
=1Sia
-----END PGP SIGNATURE-----