Re: [dnsext] Clarifying the mandatory algorithm rules

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, "W.C.A. Wijngaards" writes:
> -----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.

You can only list DS's that cover algorithms in the DNSKEY RRset.
If you don't support one of the algorithms in the DS then the zone
is insecure for that validator.  You don't add the DSs for a algorithm
until max zone TTL has expired from the initial publication of that
algorithm in a DNSKEY RRset.

> And the RFC links the algorithms in the DNSKEY to the algorithms over
> the data.

In a particular version of the zone.

> Therefore, I did not think it was allowed to link the algorithms in the
> DS to the algorithms over the data.

We're not yet.  To do incremental introduction of RRSIGs we need
to make that clearer.

> And that you had to check if algorithms (and thus their signatures)
> were missing.

Except there is nothing in RFC 4035 saying to perform this check.
The signer is told to generate them, the validator is not told to
check for them.  Yes this asymetic,  strict sender - liberal receiver
but it allow DNSSEC to work with caches learning data at different
times.  It's also is consistent with any signature validates.

> 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.

Which isn't part of the protocol.

I also note that you don't disagree with A only as being secure and
B only as being insecure.  If you are checking algorithm presence
then all should be treated as 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.

RFC4641 doesn't describe algorithm rolls it describes key rollovers within
a algorithm.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]