Re: [dnsext] Clarifying the mandatory algorithm rules

[Matthijs Mekking <[e-mail]>]

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

On 12/09/2010 04:47 PM, Edward Lewis wrote:
> At 16:19 +0100 12/9/10, Matthijs Mekking wrote:
> 
>> Because the zone operator specifically wants to be protected against
>> algorithm compromises and does that by listing more than one algorithm
>> in the DS RRset.
> 
> DNSSEC is not designed to protect the zone operator, it is designed to
> protect the relying party.  Listing more than one algorithm is done to
> reach a wider audience, it does not enhance the security as far as the
> zone operator is concerned.

Maybe it is not designed for this, but it sure is nice that it is
possible. I think both benefits apply: listing two algorithms (for
example, x and y) does not only give you algorithm compromise
protection, also a wider audience is reached. Now your zone is seen as
secure by validators that understand only x, or understand only y, or
understand both.

> In the experimentation period before the first RFCs were produced (RFC
> 2052 being the first milestone) we played with the notion of key
> strengths.  (Keys, not algorithms because back then we only had the
> unencumbered DSA and the copyrighted RSA available.)  Trying to enhance
> the concept of DNSSEC by using the notion that one algorithm is better
> or one key is better than another failed time and time again.  When
> there's a weak link involved you can't overcome it.

I am not making any assumptions about one algorithm being better than
the other, just because I use two of them.

> What if your zone is signed with algorithm 42?  You might be more
> strongly signed than anyone else.  But what if you are delegated from a
> parent using RSA/MD5?  Your strengths are negated and if algorithm 42 is
> not widely deployed you are even seen as unsigned to the masses.

No: Your strengths are negated only if you accept only one signature.
But if the validator requires to check both signatures, your strength is
not negated.

If 42 is not widely deployed, meaning most validators do not understand
algorithm 42, then most validators will only use RSA/MD5 in this case
and construct the security status of responses based on that algorithm
only. So the masses still have some sense of security, they don't see
the zone as insecure.

> So, so what if I say DNSSEC is not there to protect the zone operator. 
> Why does that mean that MUST is wrong?  The rationale is that no matter
> what you do, local policy is going to be followed. Local policy is going
> to prefer quick resolution of the query. Requiring DNSSEC to do extra or
> extraneous work is not constructive - by that I mean, once you've gotten
> a chain of trust why keep trying to find faults?  DNSSEC is not designed
> to be the last line of defense.

The additional work is there for algorithm compromise protection. And as
I argued before, yes it is local policy to let the validator fallback to
"One Signature Is Enough". But it is kind of insane to me to have a
local policy that says 'allow badly signed zones'.

> DNSSEC is never going to overcome weaknesses in the underlying
> cryptography.  Trying to do so is a futile quest and the relying party
> suffers.

And that's why I think it is nice that you can have a set of algorithms
to rely on. So in my opinion it is not futile.

But you do make a good point here: A name server using more algorithms
puts more work load on the validator. With that in mind, I am willing to
say that a SHOULD should be there.

Best regards,

Matthijs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNAe4ZAAoJEA8yVCPsQCW5SN4H/3SQocMpjakzdAEpKZneMh9r
t28+YX+1A4JufH59sEqs585Lhli3xrgBXSW3fT5PqS3QV53ZtiOizn51bXN5m7w3
dst/lsAONbrdkN7aj4wC7IYswgJbGHc0HiNZ5P2uk9nnoZxU9lwqR3JGXNN5WPct
oVZpU2irhfF1ZL3YcAJkp9lOTXrj9q9+4R5bKUKAoZc23Szn6wIEakAFKEmT39i+
kdSDBdehYnIgh71KPH1jFPXvd6LVtNHK2wQ2oG8k2gASRYd+IduQfq4WQ/qHMA3e
/ZKjPfNT1degzJU8L39M7cceLnEjk8MC00QhzzG8sgi27fCakMcekXzathOAL4U=
=BVvU
-----END PGP SIGNATURE-----