Subject: [DNSOP] Terry Manderson's No Objection on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

From: "Terry Manderson" <[email-masked]>
Date: Sat, 26 Sep 2015 02:55:17 -0700

Terry Manderson has entered the following ballot position for
draft-ietf-dnsop-root-loopback-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for writing this document and describing how it is done and
also the risks of doing this, and most importantly why it should not be
done on a whim or by default.

I concur that this is not a new idea. In fact I implemented a similar
thing during my ISP days in the late 90's and it was certainly more
beneficial then due to the low change rate of the root zone, and the
absence of DNSSEC, along with slower network speeds, and less instances
of anycasted root-serves. That said, the operational costs were the same
and they have been well covered in the doc.

Can you please pay a little attention to the first sentence of the
security considerations? Its a doozy and I had to re-read it a couple
time to be clear on its meaning.

In the appendix, different locations to get the zone by AXFR are
specified. Have you considered highlighting that the zone can be
collected from authoritative points in other ways?

e.g.

- https://www.iana.org/domains/root/files (noting ftp and http methods. 
- https://http.l.root-servers.org (and plain http)
(and of course there may well be others, but I'll refrain from boiling
that ocean)

I would also like to see the observation made that no public AXFR service
(that I am aware of) uses TSIG, so the fetching party is at the general
risk exposure of non-TSIG AXFR. Not so much in terms of modifying data in
the zone (as it's signed and the DNSSEC support on the recursive resolver
is a MUST) but in a MiTM effort to simply withhold new versions of the
root zone in a DoS frame.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 28 Sep 2015 09:53:13 +1000

In message <[email-masked]>, "Terry Mander
> root zone in a DoS frame.

And how would plain TSIG help?  TKEY and subsequent TSIG can ensure that
you are talking to the server you think you are but nothing can prevent
a MiTM DoS.

> _______________________________________________
> 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: "Paul Hoffman" <[email-masked]>
Date: Tue, 29 Sep 2015 15:45:54 -0700

> and they have been well covered in the doc.

That's good to hear.

> time to be clear on its meaning.

Earlier versions of the draft had shorter explanations, but folks wanted 
us to be more and more precise. It's hard to write a security 
consideration that says "if you do what we describe in this document but 
not that one bit over there".

> (and of course there may well be others, but I'll refrain from boiling

We considered it, but decided against it for a few reasons.

- As the first sentence says, if the zone you get comes with all the 
DNSSEC records and it validates, it doesn't mater where you got it.

- Earlier drafts listed other places that we thought were fine, but late 
in the process we discovered were not.

- We would really rather not say "authoritative" in this document. We 
didn't say that the root servers were "authoritative", just convenient.

> root zone in a DoS frame.

As Mark Andrews pointed out, TSIG doesn't help prevent MiTM blocking 
updates.

--Paul Hoffman and Warren Kumari