[DNSOP] Re: Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC

["Harvey, Joseph" <[e-mail]>]

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ý <[e-mail] <mailto:[e-mail]>>
> Sent: Wednesday, July 10, 2024 9:43 AM
> To: [e-mail] <mailto:[e-mail]>
> 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)
> [e-mail] <mailto:[e-mail]>
>
> 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 -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>