Subject: Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Aug 2018 15:14:14 -0400 (EDT)

On Tue, 31 Jul 2018, Matt Larson wrote:

> For all those reasons, I think a checksum in the zone file itself that can be verified with DNSSEC is the best option for this use case, and I like the ZONEMD solution.

Note that the checksum in this case must be at least as
cryptographically strong as the signature algorithm used
in the individual RRSIGs/DNSKEYs. This would have to be
enforced by software/RFC to prevent a downgrade attack.

Paul

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2018 15:41:31 -0400

>enforced by software/RFC to prevent a downgrade attack.

As someone else pointed out, this would be a second-preimage attack.
As far as I know, even the cruddy old hashes like MD5 and SHA-1 aren't
subject to it.  Could you explain in more detail what sort of
downgrade attack you're thinking of?

R's,
John

PS: I have no objection to making a list of hash functions for ZONEMD
that currently only includes SHA-256.  I mean, why not?

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 02 Aug 2018 17:35:34 -0700

On 2 Aug 2018, at 12:14, Paul Wouters wrote:

>> For all those reasons, I think a checksum in the zone file itself 
>> that can be verified with DNSSEC is the best option for this use 
>> case, and I like the ZONEMD solution.
>
> in the individual RRSIGs/DNSKEYs.

Not true.

If the resolver is validating, the ZONEMD only adds assurance that the 
non-signed records are there. Thus, the hash algorithm for the zone is 
unrelated to the hash algorithms in the signatures.

If the resolver is not validating, the ZONEMD assures that all the 
records are there. The strength of that assurance is the same as the 
second pre-image strength of the hash. However, the resolver cannot say 
"oh, look, now I can start resolving with what I got in the zone 
transfer": it still needs to validate every RRSIG all the way to the 
root.

> This would have to be

Given the above, what downgrade attack are you thinking of?

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Aug 2018 22:50:40 -0400 (EDT)

> unrelated to the hash algorithms in the signatures.

Then don't cover signed RRsets with ZONEMD. Then this problem goes away,
and you force implementations to validate all records before putting
them in the cache.

> If the resolver is not validating, the ZONEMD assures that all the records 
> are there. The strength of that assurance is the same as the second pre-image 
> strength of the hash. However, the resolver cannot say "oh, look, now I can 
> start resolving with what I got in the zone transfer": it still needs to 
> validate every RRSIG all the way to the root.

That's not what people are going to do. They are going to grab the
AXFR'ed data, check the checksum and throw it in the "validated" cache
and they won't revalidate every root zone entry they are about to serve.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Fri, 3 Aug 2018 13:04:26 +1000

> On 3 Aug 2018, at 10:35 am, Paul Hoffman <[email-masked]> wrote:
> 
> If the resolver is validating, the ZONEMD only adds assurance that the non-signed records are there. Thus, the hash algorithm for the zone is unrelated to the hash algorithms in the signatures.

ZONEMD also adds assurances that RRSIGs have not been removed.
ZONEMD also adds assurances that RRSIGs for unsupported algorithms have not been tampered with except for RRSIG(ZONEMD).

SIG(AXFR) was designed to validate the entire zone (no need to validate individual RRsets).
RRSIG(ZONEMD) should be able to validate the entire zone.

> If the resolver is not validating, the ZONEMD assures that all the records are there. The strength of that assurance is the same as the second pre-image strength of the hash. However, the resolver cannot say "oh, look, now I can start resolving with what I got in the zone transfer": it still needs to validate every RRSIG all the way to the root.
> 
>> This would have to be
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2018 23:21:39 -0400

>and they won't revalidate every root zone entry they are about to serve.

Why would my copy of nsd handle it differently than the copy of the
root it AXFRs now?

Also, still wondering about that second preimage downgrade attack.

R's,
John

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 02 Aug 2018 20:25:29 -0700

On 2 Aug 2018, at 19:50, Paul Wouters wrote:

>> If the resolver is validating, the ZONEMD only adds assurance that 
>> the non-signed records are there. Thus, the hash algorithm for the 
>> zone is unrelated to the hash algorithms in the signatures.
>

That only works for validating resolvers. ZONEMD also is useful for 
non-validating resolvers.

>> second pre-image strength of the hash. However, the resolver cannot 
>> say "oh, look, now I can start resolving with what I got in the zone 

A non-validating resolver doesn't have a validated cache.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Aug 2018 23:36:51 -0400 (EDT)

> A non-validating resolver doesn't have a validated cache.

The internet is no place for spoofable data in any kind of protocol.

I don't think the IETF should provide DNS-without-DNSSEC solutions,
just like we don't do SHA1 or MD5 or IKEv1 or TLS 1.0 anymore.

We should not make things more complicated to allow for dnssecless.

A non-validating resolver is on its own. Nothing can save it.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Fri, 3 Aug 2018 13:54:27 +1000

> On 3 Aug 2018, at 1:36 pm, Paul Wouters <[email-masked]> wrote:
> 
>> That only works for validating resolvers. ZONEMD also is useful for non-validating resolvers.
> 

+1.

We don’t need to split out the hash from the signature.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]