Subject: Re: [DNSOP] [Ext] Re: Comments on draft-wessels-dns-zone-digest-02

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Aug 2018 14:37:45 +0000

On 8/11/18, 10:44, "DNSOP on behalf of John Levine" wrote:

>The way that ZONEMD is defined in the draft, it's not very useful if the ZONEMD record isn't signed.

That's my read too, which is why I question the incremental benefit over relying on DNSSEC while doing the query/response over port 53 "thing".  Question, not doubt, that is.

What I'm struggling with is the applicability to other uses of the zone file.  There too, the consumer, when making use of the ZONEMD, if the record isn't signed then it could be recomputed by the manager of the repository from which the zone file came.  If the record is signed, the consumer would then need to implement DNSSEC.  'Course, one signature verification would be cheaper than "$lots" (hundreds, thousands, millions).

---

From: "John Levine" <[email-masked]>
Date: 13 Aug 2018 11:49:46 -0400

In article <[email-masked]>,
Edward Lewis  <[email-masked]> wrote:
>That's my read too, which is why I question the incremental benefit over relying on DNSSEC while doing the query/response
>over port 53 "thing".  Question, not doubt, that is.

As we may have mentioned once or twice before in this discussion, it
lets you do zone transfers over insecure channels and batch verify the
zone before using it.

I agree that the consumer needs to implement DNSSEC, but the obvious
consumer is a DNS server.

On my setup, I batch sign the zones on the primary server and rsync
them to the secondary.  The setup is reasonably secure, dedicated dns
user account on each machine and ssh for transport, but given the
number of moving parts between signing and the secondary server and
the chance of occasional bitrot, it'd be nice to be able to check that
the zone is correct and get notified of failure immediately rather
than hoping I notice odd resolution strangeness on the secondary.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Aug 2018 12:41:42 -0400 (EDT)

> That's my read too, which is why I question the incremental benefit over relying on DNSSEC while doing the query/response over port 53 "thing".  Question, not doubt, that is.

Which is why I suggested only using zonemd for glue/NS

> What I'm struggling with is the applicability to other uses of the zone file.  There too, the consumer, when making use of the ZONEMD, if the record isn't signed then it could be recomputed by the manager of the repository from which the zone file came.

The ZONEMD draft should state that before using the contents of ZONEMD,
it must be DNSSEC validated [up the chain, not just with the DNSKEY
obtained via this transfer]

>  If the record is signed, the consumer would then need to implement DNSSEC.  'Course, one signature verification would be cheaper than "$lots" (hundreds, thousands, millions).

That is the only argument in favour of using it to sign the entire zone.
And it does have merit.

My main concern is people's creativity to jump through hoops to avoid
DNSSEC, and see people using zonemd as an "alternative". At which point
origin security is not present, and transport security is very weak
as anyone can subvert the ZONEMD record as has been pointed out.

Paul

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Aug 2018 17:25:12 +0000

On 8/13/18, 11:50, "John Levine" <[email-masked]> wrote:

>As we may have mentioned once or twice before in this discussion, it lets you do zone transfers over insecure channels and batch verify the zone before using it.

Yes, I see that.  As in no more argument is needed to convince me of that.

>but the obvious consumer is a DNS server.

Maybe, maybe not.  I've seen DNS used in turnkey ways.  Nevertheless, given the complexity of DNSSEC validation, a wise implementer should re-use the parts of a DNS server for this.

(I.e., there's a lot of wacky stuff out there.  See "DNS Zone Transfer Protocol (AXFR)", Definition of Terms section [RFC 5936, Sec. 1.1] definitions of "General-purpose DNS implementation" and "Turnkey DNS implementation.  I've run across a lot of weird stuff in my studies of responder behavior [shuddering to think of these beasts as servers ;) ].)

>it'd be nice to be able to check that the zone is correct and get notified of failure

There are many existing tools for such a set up.  For one, use a VPN or in-band channel security, and/or make sure the zone file received matches the zone file sent.  (If you use AXFR, which can only run on TCP, make sure the first and last resource record are the SOA.  If you use RSYNC, use other filesystem checks - like file size for one.)

I think the use case is the "we'll put the zone on some third party server and let others [the second party] retrieve it" - that's where you would want an end-to-end "secure" set up.

This is where my "belts and suspenders" comment comes in, if whatever uses data sets from the zone as transferred will do DNSSEC validation on the sets, what's the need for a signed "checksum" of the whole zone?  What is the relying party does not do validation?

In essence, what would do DNSSEC validation for the ZONEMD and not for data sets within the zone?

---

From: "John R Levine" <[email-masked]>
Date: 13 Aug 2018 13:35:36 -0400

> Maybe, maybe not.  I've seen DNS used in turnkey ways.  Nevertheless, 
> given the complexity of DNSSEC validation, a wise implementer should 
> re-use the parts of a DNS server for this.

If the question is whether one might use this to create a kludge and shoot 
yourself in the foot, well, sure, but in the DNS world that goes without 
saying.  On the other hand, I would think that in a reasonbly well written 
DNSSEC implementation it wouldn't be too hard to reuse the code that 
checks the signature on a record received as a response to a query to 
check the signature on the ZONEMD.

> There are many existing tools for such a set up.  For one, use a VPN or 
> in-band channel security, and/or make sure the zone file received 
> matches the zone file sent.

Hey, I have a great idea.  We could make sure that the zone file received 
matches the zone file sent by including a hash of the zonee in a record in 
the zone.  Whaddaya think?

R's,
John

> In essence, what would do DNSSEC validation for the ZONEMD and not for data sets within the zone?

The glue.  I realize you could refetch all the glue and check it but 
that's a lot more work.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Aug 2018 17:50:00 +0000

On 8/13/18, 13:35, "John R Levine" <[email-masked]> wrote:

>Hey, I have a great idea.  We could make sure that the zone file received matches the zone file sent by including a hash of the zonee in a record in the zone.  Whaddaya think?

In some sense, it's re-inventing the wheel.
    
>I realize you could refetch all the glue and check it but that's a lot more work.

Some code already does that, in the sense that the glue may be needed for other queries.

If not, what happens if bad glue (meaning the address is not in use by the intended server) is included?  Either no response, lame server response, or a response with false data.  The first two are denials of service but the querier ought to (as in not guaranteed to) be able to find another source.  The latter may be a mistake (neglected decommissioning of a zone when service is transferred) or malicious (the user case usually in mind).  For the latter to "disrupt" the data would have to be correctly signed to get past DNSSEC validation.

What this keeps coming back to is - is this new invention giving us anything that DNSSEC doesn't already give us?  As in, if it seems that DNSSEC is needed to validate it, why not just validate the data we are after?