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

[ondrej at sury.org]

Just to clarify - I am not proposing we stop generating signatures for all 
algorithms. I think that's a good practice. I am proposing to stop making 
fuss every time somebody fails to do so. And we should rip out any code 
that allows the recursive DNS operator to shoot herself into the feet.

O.


On 17 November 2017 07.39.43 Mark Andrews <marka at isc.org> wrote:

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