Re: [dnsext] Clarifying the mandatory algorithm rules

[Phillip Hallam-Baker <[e-mail]>]

There are two considerations here:

1) Ensure that a service is available as long as there is an
acceptably secure path
2) Enable reliance of weak algorithms to be discontinued before the
algorithm is broken

It is very easy to meet the first at the expense of the second. And
when the real life operational requirements are concerned, we have
problems with TLS in this respect as well.


The ability of a relying party to process an algorithm does not mean
that the relying party trusts it as secure.

In particular an RP may process an algorithm it does not accept as
secure. This is necessary since by default there is no authentication
on DNS at all


One concern here is that we do not want to force zones to discontinue
signing with an obsolete algorithm prematurely because that is going
to weaken the security of their site.


In the normal course of action, an RP that sees a site advertise 2
algorithms, only one of which is trusted, will only process the
trusted one and simply ignore the other, even if the trusted algorithm
fails.

But the same RP that visits a site that advertises only the untrusted
algorithm should probably process the chain and check for consistency
in any case since the alternative is to accept the data without any
checks at all.

If an RP sees a site advertise two algs and both are trusted, the RP
should probably choose one and accept the records if it succeeds.
Otherwise it should make a second attempt but the site cannot rely on
that.


On Thu, Dec 9, 2010 at 8:44 AM, Edward Lewis <[e-mail]> wrote:
> At 10:59 +0100 12/9/10, Matthijs Mekking wrote:
>
>> Although this is local policy, I also think it is bad policy for a
>> validator to allow algorithm compromises and badly signed zones. Thus, I
>> would go for a MUST here.
>
> The reason it can't be a MUST is that a zone may be signed with algorithm
> 42.  If a resolver does not know algorithm 42, how can it determine whether
> the signature using algorithm 42 is valid or invalid?
>
> Let's say a zone is signed by algorithms 5 and 7.  (A choice made
> specifically because the two algorithms have the same mathematical
> properties. ;))  What would you think if you received a set of data and
> signatures and discovered that the algorithm 5 signature validated the
> signature but the algorithm 7 signature did not.  What if the reason were
> cryptographic?  What if the reason was that the algorithm 7 signature had
> simply expired (with or without NTP running)?  What if the reason was that
> the algorithm 7 signature had not yet entered its effectivity period?
>
> If you can establish a chain of trust to a data set, why withhold it from
> the application requesting it in case you find that there is also a
> signature that fails?
>
> Assume a set of data has a legitimate signature in algorithm 5 that
> validates and you see an algorithm 7 signature that does not validate?  What
> if the cause of this was that an attacker wanted to perform a Denial of
> Service by applying an intentionally bad signature (which is trivial to do)
> to guarantee a failed chain of trust?  It's like allowing someone to say
> "don't trust the authorities, I'll insert some doubt so you won't use the
> information."
>
> When you consider that it is far easier to insert harmful bad signatures
> than harmful bad data (because the latter requires a valid signature), you
> have to build the (or any security) protocol to be somewhat skeptical of
> it's own potentially-false positives.
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis
> NeuStar                    You can leave a voice message at [phone]
>
> Ever get the feeling that someday if you google for your own life story,
> you'll find that someone has already written it and it's on sale at Amazon?
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>



-- 
Website: http://hallambaker.com/