[dns-operations] Missing algorithm 8 signatures in .museum zone

[Mark Andrews]

> On 17 Nov 2017, at 9:40 am, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> 
> 
>> On Nov 16, 2017, at 5:08 PM, Mark Andrews <marka at isc.org> wrote:
>> 
>> If a algorithm is too weak then it should not be used to validate at all.
>> Insecure is an acceptable status.  If it is not too weak the what is the
>> issue with using any algorithm?
>> 
>> A downgrade attack can only be successful if you continue to use a
>> algorithm once it has been broken.
> 
> Yes, but when an algorithm is broken (or more typically develops enough
> issues to be questionably secure) it is often not possible to promptly
> withdraw it from service.  When multiple algorithms are fielded, it is
> advantageous for the verifier to use just the strongest that is mutually
> supported.
> 
> With DNSSEC, such agility of course carries the cost of requiring every
> RRset's RRSIG to be signed with *all* the algorithms in the DS RRset.
> So if the consensus is now that this is too burdensome a requirement,
> then perhaps this benefit of agility is lost, and so migration away
> from weakened algorithms would not immediately close the hole when
> a stronger one is added, but rather only when the weaker one is
> withdrawn…

No one, apart perhaps Ondrey, is suggesting that we don’t generate all
the signatures.  It has always been local policy whether to check that there
is a valid signature for all algorithms in the DS or not.  It was checking
if there was a valid RRSIG for each algorithm in the DNSKEY set that was
the problem.

Nobody is saying that you can’t have a local policy that says “only use algorithm
A when both A and B are in the DS RRset”,  The rules for signing permit such
a policy.

There however isn’t a rule that say you MUST fail if there isn’t a RRSIG for
each algorithm in the DS RRset, let alone check that it is valid.   You can’t
check algorithms that you don’t implement.

The signing rules allow for several different validator policies.

If we were more clueful when designing DNSSEC RRSIGs would have a list
of algorithms that should be present in the RRSIG RRset as part of its contents.
We could still add such a feature but it would require a algorithm roll to do so.

At the start of the signature field you add a “length + expected algorithm list”.
You would reject any RRset where this list is inconsistent.  You would reject
any RRset where there are not a RRSIG for each of the algorithms.

This would address some of the loose consistency issues.

Mark

> -- 
> -- 
> 	Viktor.
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org