Hi, On 8/11/22 17:56, Phillip Hallam-Baker wrote:
Looks to me like there is a serious problem here.
...
Won’t go into extreme detail here as researcher’s slides will be available tomorrow.
The slides are now available: http://i.blackhat.com/USA-22/Thursday/US-22-Heftrig-DNSSEC-Downgrade-Attacks.pdf For the benefit of all, in a nutshell: a) Slides 1-21 and 32-35: DNS/DNSSEC intro, refresher on IETF-recommended algorithms b) Slides 22-25: Attacker generates DNSKEY with colliding DS record, then takes over zone --> assumes very broken DS digest algorithm --> if multiple digest types present, this allows "downgrade" to "weakest" (whatever that means) c) Slides 26-31: Attacker generates RRSIG without knowing private key, then takes over zone --> assumes very broken signing algorithm --> if multiple algorithms present, this allows "downgrade" to "weakest" (whatever that means) d) Slides 36-43: Attacker strips RRSIG or rewrites algorithm, so validator receives only unsupported algorithm --> some resolvers pass this as "insecure" instead of "bogus" (even when DS indicates a supported algorithm) --> these are implementation bugs at some resolver operators (should be fixed) --> Google/Cloudflare bugs originally discovered by Nils Wisiol, sparking further analysis* e) Slides 44-47: Attacker strips all DNSKEY/RRSIG but one, so validator receives only unsupported DNSKEY/RRSIG --> some resolvers pass this as "insecure" instead of "bogus" (even when DS indicates a supported algorithm) --> these are implementation bugs at some resolver operators (not sure if fixed) f) Slides 48-51: --> Recommendation and wrap-up: RFCs need some clarification for d) and e) On 8/11/22 17:56, Phillip Hallam-Baker wrote:
NSEC record specifies what is signed but not the algorithm used to sign. DNSSEC allows multiple signature and digest algorithms on the same zone. If a zone does this, validators are prohibited from rejecting records only signed using one of the algorithms rather than both.
...
This definitely needs fixing.
I agree that the specs should more clearly say that when a validating resolver sees a (supported?) algorithm in DS without seeing corresponding RRSIG authenticated via such DS record, the response MUST be bogus. Apart from that: What else needs fixing? (You mentioned something with NSEC.) Best. Peter * Further analysis occurred in collaboration with the Black Hat authors, but led to disagreement. The collaboration ended, and a flawed paper [1] was later uploaded on arXiv by the Black Hat authors. As it had Nils' and my name, but not our consent, we had the paper withdrawn. Besides the numerous technical and editorial errors in the paper, we in particular disagree with the conclusion that DNSSEC algorithm agility causes the problems. It's just bugs. [1]: https://arxiv.org/abs/2205.10608 Personally, I also don't believe that the claim of Section 5.2.1 has been experimentally demonstrated. It says: "[...] the adversary manipulates the algorithm number in an RRSIG RRset over DS RRset to some unsupported algorithm. This is required to disable DNSSEC validation of the DS RRset. The adversary manipulates the DS to correspond to its own key-pair. [...] Once this DNSKEY is stored in cache, the adversary can inject any record of its choice. [...] [...] it immediately affects all the subdomains of the poisoned domain. In particular, the adversary can further create secure delegations for the subdomains using its own malicious key. Launching this attack against Google public DNS would have severe consequences for all the domains under com.." [2] That would require that a resolver would regard a DNSKEY as trusted based on a DS record that it has not validated, and use that DNSKEY later to generate responses with AD bit for delegated names. While that is conceivable, it is conceptually different from finding d). At the time when Nils and I were part of the collaboration, the measurement tooling [3] was not capable of this measurement. There is no indication that it was later extended. I will therefore consider that finding a fabrication until the data is made available. [2]: Original revision of the paper (pre-withdrawal): https://arxiv.org/pdf/2205.10608v1.pdf [3]: https://github.com/nils-wisiol/dns-downgrade-attack (In the arXiv metadata, it is recorded that the paper was withdrawn upon request of one of the authors (me), and not because it was found to be inaccurate. Co-authors did not retract the claim from Section 5.2.1, and instead opposed withdrawal until a lawyer got involved. It is peculiar that the claim still was not made in the Black Hat talk, and I'm actually curious to see data that support it.) -- https://desec.io/ _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
