Re: [dnsext] Clarifying the mandatory algorithm rules

[Matthijs Mekking <[e-mail]>]

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

Ok, so let's try to come to a reasonable clarifying text:

- -------------------------------------------------------------------------
Section ?.? Clarifying the validators interpretation regarding multiple
algorithms.

RFC 4035, section 2.2 talks about Zone Signing. It mentions that

 "There MUST be an RRSIG for each RRset using at least one DNSKEY of
  each algorithm in the zone apex DNSKEY RRset".

This is a requirement at the server side, not the client side. In other
words, when a validating resolvers is in the process of validating a
RRset, it SHOULD NOT expect a RRSIG of each algorithm that is in the
zone apex DNSKEY RRset.
- -------------------------------------------------------------------------

This only fixes the misinterpretation on the expectation a validator may
have. It does not deal with algorithm downgrade protection at all (as
some may believe does not exist in DNSSEC). If there is need for
clarifying algorithm downgrade protection, or its non-existence, I
suggest something in the line of:

- -------------------------------------------------------------------------
Section ?.? Algorithm downgrade protection.

The validator could check that there are RRSIG records for each RRset
using at least one DNSKEY of each algorithm in the DS RRset, published
in the parent zone. This ***

*** Choice here
- - is however NOT RECOMMENDED. ['the one signature is enough approach']
- - is OPTIONAL. ['leave the choice to the implementation' approach]
- - is RECOMMENDED behavior. ['algorithm downgrade protection' apprpach]
- -------------------------------------------------------------------------

Best regards,

Matthijs



On 03/18/2011 06:07 PM, Edward Lewis wrote:
> I should add...just because "there's supposed to be X" doesn't mean X
> has to be there.  If I'm looking for X and it's not there, we have a
> failure.  If I'm not looking for X and it is not there, "no harm, no
> foul."  (The latter is the same as not needing X and it's there anyway.)
> 
> At 12:59 -0400 3/18/11, Edward Lewis wrote:
>> At 9:36 -0700 3/18/11, Casey Deccio wrote:
>>
>>
>>> Okay, so the signer sets the expectation of the validator using the
>>> algorithms in the DS RRset.  Now, does this expectation hold for
>>> simply authenticating the DNSKEY RRset or for all zone data?
>>
>> No, the specification sets expectations.  I don't mean to be a pain,
>> but the first words say this: "The reason for the specification is to
>> set the expectation."  I mean that in the strictest sense.  The
>> validator knows there's supposed to be X because the spec says so.
>>
>>> For example:
>>>
>>> - DS RRset has only algorithm 5
>>> - DNSKEY RRset signed by a DNSKEY matching the DS (alg 5)
>>> - DNSKEY RRset contains DNSKEYs with algs 5 and 3
>>> - DNSKEY with alg 3 signs A RRset.
>>>
>>> Is there a valid chain to the A RRset, or is it a protocol failure?
>>
>> Depends.  If the validator knows both 3 and 5, then it can build a
>> chain and it's cool.  If the validator only knows 5, then there's a
>> missing piece.  If the validator only knows 3, there's no chain to the
>> data.
>>
>> In summary:
>> Validator knows 3 & 5 - validates
>> Validator knows only 3 - data is accepted as not-signed.
>> Validator knows only 5 - service failure as *expected* signature is
>> not found*
>> Validator doesn't to 3 & 5 - accepted as not-signed
>> Validator doesn't do DNSSEC - accepted as not-signed
>>
>> *not found = not obtainable, can't get it, ...
>>
>>> Following the principle of "if one chain works, it succeeds", I would
>>> say
>>> that it is valid.  But it's unclear whether this is part of the
>>> expectation
>>> of the signer for the validator, and even the paragraph quoted above
>>> seems
>>> to declare it a protocol failure--although I well understand your
>>> position
>>> on principle.  Whether it is valid or not, I believe it should be
>>> worded explicitly to avoid ambiguity and accurately convey principle.
>>
>> It is always up to the validator to decide if it accepts the data.
>> Local policy and DNSSEC is about protecting the cache.  DNSSEC is NOT
>> designed to enforce proper operations, it is NOT to force the zone
>> admin into doing anything.  Remember, DNSSEC is optional to the
>> protocol, it's the validators that want to pull the data for protection.
>>
>> -- 
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>
>> Edward Lewis
>> NeuStar                    You can leave a voice message at
>> [phone]
>>
>> Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
>> Son: "Waah!"
>> _______________________________________________
>> dnsext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsext
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNk4zDAAoJEA8yVCPsQCW502MH/0unZXAo8KqLpwDrXbBBaGps
5rm7eA6rgipU1y99QOMZOggzu5XsI3VVZq8LiTIzKgBB69iufN392v/4afWiEgcW
LGdETtYwQmaif+Rj7+3UhjbSFJj7h2yPUlDvFoT66YOr7HaV+Ow9niYSnTbxmZgV
L/AWNjdpMsfmFoxk9OfJZlYnfgPA2gK4UyUG5YduwybeW1REcqyoQ3V73HnkhZod
SZ5QDHp/mRj4JjlACwSPSg5cQO1hURfp4r43oad0mO2Y1p2cjknp/cF9kcgI2VQu
bBSQ+0oEz55N/8yqzKznfY9tsUWwfsnBmjkMyA8mKD9BuzstScCvXs71K1Dz3SM=
=vrOn
-----END PGP SIGNATURE-----