Re: [dnsext] Clarifying the mandatory algorithm rules

[Matthijs Mekking <[e-mail]>]

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



On 03/31/2011 09:03 PM, Edward Lewis wrote:
> Ironically, I was thinking about this issue when the mail came in
> yesterday.
> 
> At 22:04 +0200 3/30/11, Matthijs Mekking wrote:
> 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.

I would than say "it can expect to find" (not make it a rfc 2119 term)

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

iQEcBAEBAgAGBQJNlN8qAAoJEA8yVCPsQCW5g9gIAJzi7c+Ix9Woyf+iwWAuVGYL
6+K4eHbAxibFCs1qimGTC4kV8CWCwdZL5c1+cZ6lZzLSH6TePw9LUTtivxRQhk8i
DMgRt8wgOZ4LJB4y3M10BUaPQh0xnG1HtPiRJtd1EVrW4b4wSLFEEXUFZtVPIZwe
7RqC7YCPL8bK9U4wJU+4THn1x3hWpOgywgi+DKdk66uCzBnxMcZpzIcgkmRaAzGn
6MAcBTu77nqTz6LwOCT59fLwI1KnOzvR5eFXUjQvnCaEwBnyMmJztK5suId587hC
dYVtDvMik8cs4egZEEPjlJviHIcvdW4ZjOf0gngn9xCWmcCDH8m8368TShtveEA=
=zdlJ
-----END PGP SIGNATURE-----