Hello Ondřej, I am sorry for the long delay in responding to your concerns.
As you pointed out, post-quantum DNSSEC does present significant challenges, including critical operational considerations. This is why the Verisign Labs team has been socializing the need for research and is supporting the recent proposal to form a new Post-Quantum DNSSEC RG (POQD) research group (see the side meeting – PQC DNSSEC Research). The purpose of the research group is to study how DNSSEC can transition to the use of one or more PQC algorithms and provide a venue for that research within the IRTF and IETF. The primary goal behind MTL Mode is to provide a mechanism that can reduce the operational impact of the post-quantum signature algorithms currently being standardized. We are particularly interested in applying MTL Mode to the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) being standardized by NIST. SLH-DSA’s conservative design, based on hash function security properties only, provides a solid foundation for long-term cryptographic resilience in infrastructure protocols such as DNSSEC. draft-harvey-cfrg-mtl-mode specifies the underlying cryptography and algorithm selection for MTL mode. draft-fregly-dnsop-slh-dsa-mtl-dnssec applies MTL mode to DNSSEC. We agree that both security and operational considerations motivated by your concerns (and perhaps protocol changes too) need to be added to both documents. Managing the impact of malicious actors is already a concern for DNSSEC, independent of MTL mode. Indeed, there are already scenarios in which a malicious actor can potentially cause other parties to perform extra work and significantly impact their ability to resolve DNS queries. DNSSEC as it is defined today has documented several of these operational concerns, such as setting the inception and expiration values along with the TTL on the RRSIG records appropriately. This important operational consideration (as described in RFC 6781) could be exploited by systems currently in operation, and while current signatures are small enough that this may be manageable, future updates with larger signatures would be a concern. Validating resolvers do not have control over these parameters and detection of this in an existing system is dependent on factors like query rates to detect bad behaviors. We agree with the points you have made on attack scenarios for MTL mode. A few general observations follow as a starting point for further discussion. 1. An honest DNSSEC signer is expected for normal DNSSEC operation. An honest signer implementing MTL mode can reduce its operational impact by following practices such as signing DNS records in batches to reduce both the number of signatures and the computational impact of the underlying signature algorithm (e.g., SLH-DSA) on both the signer and the verifier. A preferable batch size and the timing of batch generation will likely depend on specifics of the zone file and the frequency of updates to the zone file. The verifier’s work in this case can thereby be bounded by the frequency of batch signing. 2. Malicious signers can indeed add operational risk to MTL mode verifiers, as you have observed. For example, a malicious signer can potentially sign one record at a time, on demand, in response to a validating resolver’s lookup request, rather than precomputing and/or batching signatures. In this case each signature would involve a new Merkle tree leaf node and would therefore require the validating resolver to request a new signed ladder covering the new leaf node each time. The benefits of MTL Mode in reducing size and computational impact of the underlying signature algorithm would not be realized in this scenario. This scenario would have slightly more operational impact than the underlying signature algorithm because the signer would send a condensed signature and a full signature, which together are slightly longer than an underlying signature, and an additional query would be involved (one for the condensed signature, one for the full signature). 3. Two types of malicious responses can be returned by the malicious signer. Malicious responses with bad signatures require less work for the malicious signer but would result in signature verification failures, making the malicious activity easier to detect by the verifier. Malicious responses with good signatures would make the malicious activity harder to detect without comparing to a baseline for “normal” frequency of zone file updates resulting in new leaf nodes and signed ladders, full signatures vs. condensed signatures, etc. However, good signatures would require more work by the malicious signer. Verifiers will need to bound their follow-up queries and check that signatures values, like validity period and the signed message ID, are within reasonable bounds to help protect against malicious responses. 4. On-path attackers can also have significant impact on validating resolvers. Such attackers by assumption do not have access to the private key and therefore cannot generate new signatures, which limits their impact. However, they can replay valid existing signatures and send bad signatures. 5. Malicious clients (off-path attackers) can also potentially add operational risk to a validating resolver even when the signer is honest. Such clients could model when the zone has changed though direct queries to the authoritative name server or through other zone probing techniques. They can then perform queries to the validating resolver to force lookup of a newly updated record in the zone and its accompanying signature. You also raise an interesting question about “chained queries” which is something we should explore further. Most, if not all, of the above can be addressed in the drafts. We’ll also add text describing mitigation strategies. We appreciate your feedback and look forward to further observations and questions. Regards, Joe Harvey _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
