Re: [dnsext] Clarifying the mandatory algorithm rules

[Edward Lewis <[e-mail]>]

Ironically, I was thinking about this issue when the mail came in yesterday.

At 22:04 +0200 3/30/11, Matthijs Mekking wrote:
>-----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.
>- -------------------------------------------------------------------------

That's not right either, unfortunately, I want to avoid "SHOULD NOT 
expect" in the text.  How about trying this for the last part of the 
last sentence.

...it SHOULD expect to find an RRSIG of *any* algorithm that is in 
the zone apex DNSKEY RRset.  As a validator ought to be satisfied in 
building one chain of trust acceptable to local policy, a validator 
SHOULD NOT check that all signatures are received.  Doing so 
represents a distraction from the goal of returning an answer 
swiftly.  A validator MAY have a configuration option to perform a 
signature completeness test to support troubleshooting.

The *any* there is important, but not the *'s.  I added them to 
stress the "any."

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


NOT RECOMMENDED, I consider it unnecessary work towards the goal of 
finding what the client asked for.  That is, in a default setting. 
The principle that I am pinning this on is that one of the strengths 
of the DNS protocol is a fast response.

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

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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!"