To be perfectly clear: I think this is a major flaw in the proposal that needs to be addressed and not something to be just discussed in the “section” of the draft before the implementors start even looking at the possibility of implementing the MTL mode.
I’ve raised this immediately when the MTL mode was first presented to the implementors during IETF in Prague, I’ve sent you this feedback on 24.05.2024 in a personal email to the Verisign researchers. I don’t feel heard as the only feedback I got was whether ISC would join hackathon to implement the MTL mode in BIND 9. My view is that an ability to attacker to make the resolver do expensive work is total red flag. Attackers can contain a fleet of domains, each with own DNSSEC keys. What about an on-path attacker - that’s suddenly an attack that can cause DoS for all the domains and users as the resources will be exhausted to fetch the large keys. What about an off-path attacker, can an attacker cause the new fetch? Repeatedly? A resistance against the repeated key refetching needs to be built into the protocol, and I am not convinced that just putting limits on frequency is going to be enough. There are variants to this - can an attacker make the resolver to download and validate many keys through chained queries through different domain names each with own key with zero TTL? Repeatedly? I would like to have a path to PQC for DNSSEC, but my experience with implementing DNS and defending it against attackers (and clever researchers alike) tells me that we are not there yet with this proposal. Convince me that I am wrong. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 15. 7. 2024, at 17:49, Harvey, Joseph > <jsharvey=40verisign....@dmarc.ietf.org> wrote: > Hello Ondřej > > Thank you for taking the time to review the documents and provide feedback. > You make a very interesting observation that a malicious server operator > could force a validating resolver to always fetch the larger full signature > to validate (or try to validate in the case of bad signatures) the signatures. > > Our submitted draft is a work in progress, and we agree that there should be > discussion in the draft on this and other potential scenarios, risks, and > mitigations. We will add a section to the draft for that purpose including > discussion around this issue. > > We will keep you posted on the future updates and welcome any other feedback > you may have as this draft evolves. > > Regards, > Joe Harvey > > > > -----Original Message----- >> From: Ondřej Surý <ond...@isc.org <mailto:ond...@isc.org>> >> Sent: Wednesday, July 10, 2024 9:43 AM >> To: dnsop@ietf.org <mailto:dnsop@ietf.org> >> Subject: [EXTERNAL] [DNSOP] Stateless Hash-Based Signatures in Merkle Tree >> Ladder Mode (SLH-DSA-MTL) for DNSSEC >> >> Caution: This email originated from outside the organization. Do not click >> links >> or open attachments unless you recognize the sender and know the content is >> safe. >> >> Hi, >> >> since draft-fregly-dnsop-slh-dsa-mtl-dnssec-02 and draft-harvey-cfrg-mtl- >> mode-03 have been published now, I would like to discuss something I noticed >> when this was first brought to my attention during IETF in Prague. >> >> The Section 6.2 says: >> >>> As described in 9.2 of [I-D.harvey-cfrg-mtl-mode], when a verifier >>> receives a condensed signature, the verifier determines whether any of >>> the MTLs it has previously verified includes a rung that is compatible >>> with the authentication path in the condensed signature. If not, then the >> verifier requests a new signed ladder. >> [...] >>> Accordingly, a resolver SHOULD first query a name server without the >>> mtl-mode-full option, and then, if needed, re-issue the query with the >>> mtl-mode-full option. Since responses to queries with the >>> mtl-mode-full option are expected to be large, it is RECOMMENDED that >>> queries with the mtl-mode-full option be issued over transports (e.g., >>> TCP, >> TLS, QUIC) that support large responses without truncation and/or >> fragmentation. >> >> I have pointed out that a malicious zone operator can return a different run >> effectively making the resolver request a new signed ladder every time. This >> effectively removes any benefit that the resolvers gain from using the MTL >> mode. >> >> Again, if I am understanding the protocol correctly, it should be even >> possible >> to pre-generate the different answers and just mess with the resolver by >> invalidating the previously received response by using low TTL numbers and >> providing different answers every time. >> >> Please correct me if I am wrong. >> >> Cheers, >> Ondrej >> -- >> Ondřej Surý (He/Him) >> ond...@isc.org <mailto:ond...@isc.org> >> >> My working hours and your working hours may be different. Please do not feel >> obligated to reply outside your normal working hours. >> >> _______________________________________________ >> DNSOP mailing list -- dnsop@ietf.org <mailto:dnsop@ietf.org> >> To unsubscribe send an email to dnsop-le...@ietf.org >> <mailto:dnsop-le...@ietf.org> > > > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
