Subject: Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 8 Jul 2018 20:28:58 -0400

> On Jun 22, 2018, at 6:58 AM, Petr Špaček <[email-masked]> wrote:
> 
> On 21.6.2018 22:31, Hugo Salgado-Hernández wrote:
>> On 22:09 21/06, Shane Kerr wrote:
>>>> Dne 1.6.2018 v 12:51 Shane Kerr napsal(a):
>>>> 
>>>> Hmm, can you share some details about your experience?
>>>> Did you find out when the data corruption took place?
>>>> a) network transfer
>>>> b) implementation bugs (e.g. incorrectly received IXFR)
>>>> c) on disk
>>>> d) some other option?
>>> 
>>> I don't know. I have seen incorrectly transferred zone files both in
>>> BIND
>>> and NSD slaves. IIRC our solution was to include sentinel records in
>>> the
>>> zone files to spot problems, take the node out of service, and force a
>>> re-transfer. This of course won't work if you are slaving zones that
>>> you do
>>> not control, and it doesn't prevent a small window of time when the
>>> servers
>>> are operating with broken zones. TSIG was being used.
>> 
>> We have also seen broken transfers between secondaries. Our solution
>> is to dump the zone after transfer, calculate a hash and compare. We
>> would benefit from having a ZONEMD record inside the zone.
> 
> If the zone got broken during TSIG-secured transfer then it was not most
> probably not caused by network problem because TSIG would have caught that.
> 
> Honestly I do not think it is worth the effort because all the
> complexity does not help to prevent implementation bugs, I would say it
> even increases probability of a bug!
> 
> What is left is bug on auth and/or slave sides and in that case there is
> no guarantee that
> a) master did not compute ZONEMD from already broken data
> b) slave verification of ZONEMD actually works
> 
> 
> If we wanted to catch problems with implementation we need something
> which is outside of the DNS stack we are attempting to check, be is
> simple checksum or some fancier crypto.
> 
> I can easily imagine OPENPGPKEY RR located at _zonefile.apex.example
> node and an utility which would extract OPENPGPKEY RR from the zone file
> and verify that the zone file signature (either detached or in .gpg
> file) can be verified using that key (+ add DNSSEC into the mix if you
> wish).
> 
> -- 
> Petr Špaček  @  CZ.NIC
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

+1 
I spent lots of time earlier this century along with Johan Ihren trying to figure out how to 
secure the transfer of a particular zone (the root) to any resolver. 
The only sane way is to not transfer the zone over AXFR as any intermediary can mess with the zone contents mostly in the case of “glue” records,
thus transferring the zone over HTTPS or RSYNC with a PGP signature over the zone file is the only viable solution going forward. 

Historical background: SIG(AXFR) was rejected because it required putting the zone into canonical order and calculating the signature, 
in the case of dynamic update this is a real expensive operation, thus we got rid of it. 

Olafur

---

From: George Michaelson <[email-masked]>
Date: Mon, 9 Jul 2018 11:02:55 +1000

So if I look at what you said, what I see is "inband, canonicalization
is a cost we don't want to bear, to produce a signed product of whole
of zone" and "if we accept knowledge of a PGP or other external key as
the moment of trust, out of band, disordered but specifically testable
as *this file* is signed by *known key* is workable.

wow. Firstly, I thought canonicalization was a given: we have
definitions of canonical zone order for other reasons (NSEC*) don't
we?

secondly, I absolutely (and no sarcasm implied or intended, I really
mean it) applaud the pragmatism. If we can move to a world which
accepts the root is a resource which can routinely be fetched out of
band, validated out of band, and then locally bound to a DNS server,
we've probably moved on.

in-band is great. but, sometimes, its really hard.

So how about use of a PGP key which is a payload in TXT signed over by
the ZSK/KSK so the trust paths bind together?

fetch one DNS record +sigs, check against the TA (which has to be a
given) and then..

-G

On Mon, Jul 9, 2018 at 10:28 AM, Olafur Gudmundsson <[email-masked]> wrote:
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
>
> +1
> The only sane way is to not transfer the zone over AXFR as any intermediary
> can mess with the zone contents mostly in the case of “glue” records,
> thus transferring the zone over HTTPS or RSYNC with a PGP signature over the
> zone file is the only viable solution going forward.
>
>
> Historical background: SIG(AXFR) was rejected because it required putting
> the zone into canonical order and calculating the signature,
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 8 Jul 2018 21:23:56 -0400

George, 

The reason I should have stated before is 
if the zone fails the check we should not tell the server to load it 

There are roughly 3 kinds of zones in based on update frequency 
— almost Never 
— On schedule 
— All the time 

Calculating the zone “digest” is only feasible in the third case when the zone is small 
i.e. imagine calculating the updated zone digest for .org (not to mention .com) every time there is an update to the zone. 
SO  if the problem statement that it only applies to the first two then you may have a case for a zone digest. 
For the record root zone falls into the second category and my private zone falls into the first one.

Olafur
PS: Also for the record I think AXFR is a horrible protocol hack. 
PPS: I almost agree with Prof Bernstein that rsync  is a better solution, from an interoperability perspective. 

> On Jul 8, 2018, at 9:02 PM, George Michaelson <[email-masked]> wrote:
>

---

From: Joe Abley <[email-masked]>
Date: Sun, 8 Jul 2018 18:27:27 -0700

> definitions of canonical zone order for other reasons (NSEC*) don't

NSEC is concerned with the ordering of owner names.

RRSIG is concerned with the ordering of individual RRs in an RRSet.

Unsigned RRSets (e.g. glue, NS RRSets above a zone cut) are unordered.
You could apply the same rules (RFC4034 section 6.3) to sort them into
canonical order, but I think you could also not do that and still have
a compliant implementation of DNSSEC.

Joe

---

From: George Michaelson <[email-masked]>
Date: Mon, 9 Jul 2018 11:34:03 +1000

> PPS: I almost agree with Prof Bernstein that rsync  is a better solution, from an interoperability perspective.

AXFR is reductionism/dogfooding of self supporting protocols. Some
people hate the idea of outside dependencies. You see this in TLS, not
wanting to dive into DANE and DNS derived keying materials.

Please, not rsync. I live in another domain where rsync is used, and
its horrible. HTTPS is fine I think.

-G

---

From: Mark Andrews <[email-masked]>
Date: Mon, 9 Jul 2018 11:35:32 +1000

So what if it is not feasible for COM and similarly sized zones?

At the moment we have one zone where we need a zone signature so that the zone contents can be loaded into every recursive server.

The question we should be asking is "Is SIG(AXFR) a good fit for the root zone?” not whether is is a good mechanism for all zones because quite frankly there are very few zones that you would want loaded into all recursive servers.

“.”, “arpa”, “in-addr.arpa” and “ip6.arpa” would be about it.  Does anyone else have any others?  Any zone would necessarily be small. 

Mark

> On 9 Jul 2018, at 10:28 am, Olafur Gudmundsson <[email-masked]> wrote:
> 
> 
> 

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

---

From: Mark Andrews <[email-masked]>
Date: Mon, 9 Jul 2018 11:57:39 +1000

> On 9 Jul 2018, at 11:27 am, Joe Abley <[email-masked]> wrote:
> 

You need to sort them or you need to provide a mechanism that preserves the existing order.

I actually think we could design a system that works for in-band and dynamic update.  Add a XSIG (record where the XSIG is RRSIG(hash(NS and other records in the zone up to the next secure delegation in DNSSEC)).  For NSEC this becomes the NS records and glue below the NS.  This is incrementally generatable.

Mark

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 8 Jul 2018 23:39:39 -0400

> On Jul 8, 2018, at 9:35 PM, Mark Andrews <[email-masked]> wrote:
> 

So the followup question is 
Should we burden the Auth Server implementations with this calculation if the usage case if 4 zones ? 
or is this better handled by external tools ?
DNS Camel says ? 

Olafur

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 9 Jul 2018 21:39:44 +0000

> On Jul 8, 2018, at 5:28 PM, Olafur Gudmundsson <[email-masked]> wrote:
> 
> 
> +1 

I respectfully disagree. 

I dislike PGP (and S/MIME) for a couple of reasons.  For one, I think it limits the use cases to non-AXFR.  You would have to either keep the original file in-tact (not just ordering, but character-per-character) if to be redistributed, or you would have to define a sorting for the data.  Any reformatting of the data (whitespace etc) invalidates it.  Additionally, you'd have to choose between detached signatures (which I think are a bad idea) or use a PGP attached signature format, in which case you are no longer distributing a file that could be directly loaded into a name server. 

Regarding HTTPS/RSYNC, that would be irrelevant.  If the data is secured then the transport doesn't matter at all.

> Historical background: SIG(AXFR) was rejected because it required putting the zone into canonical order and calculating the signature, 

Thanks for that.  This little tidbit was lost in the process of editing those RFCs.

> in the case of dynamic update this is a real expensive operation, thus we got rid of it.

I agree that dynamic updates complicate zone digests.  It could be made to work without sorting the whole zone, but some sorting would be required.  But in general I don't think the complexity of digests for dynamic zones is worth it.  

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 9 Jul 2018 21:47:53 +0000

> On Jul 8, 2018, at 6:02 PM, George Michaelson <[email-masked]> wrote:
> 

Currently in the zone digest draft DNSSEC is not mandatory.  That is, the zone
needn't necessarily be signed and a receiver need not perform the validation if
they don't want to.

Even without DNSSEC the digest gives you a little protection from accidental corruption.  But not from malicious interference of course.

It seems kind of silly to me to double up on public key cryptosystems.  We already have keys attached to zones and software that generates and validates signatures. 

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 9 Jul 2018 21:52:05 +0000

> On Jul 8, 2018, at 8:39 PM, Olafur Gudmundsson <[email-masked]> wrote:
> 

IMO we should build something that works either way -- in the name server software or with external tools. 

DW

---

From: George Michaelson <[email-masked]>
Date: Tue, 10 Jul 2018 09:36:34 +1000

There's arguments both sides about cross signing, counter signing and
independent self-signing. If you want to promote out of band zone
exchange, it has to be signed. The key it signs with is immaterial if
you either direct knowledge of the PK in a PKI, or accept a trust
anchor relationship over it, or a web of trust.

So do you prefer (for instance) that the ZSK be used outside of DNSSEC
to sign a detached signature over the file, irrespective or content
order, if the file is to be made available? Because if you basically
prefer its *not signed* for this mode of transfer, you've stepped
outside the model: you now demand the file is checked on load, element
by element, against the TA, rather than being integrity checked by a
MAC signed by the issuer, which permits eg direct binary loadable, or
other states.

-G

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 10 Jul 2018 00:05:15 +0000

George,

> On Jul 9, 2018, at 4:36 PM, George Michaelson <[email-masked]> wrote:
> 

I'm not here to promote out-of-band distribution, but I think its going
to happen (especially for the root zone) and I want something that works
just as well for in- and out-of-band distribution.

I think it makes sense that name server software, whether recursive or
authoritative, can use a technique like this to verify zone data, whether
it is loaded from disk or received over the network.  

The key may be immaterial, but I think the barrier to implementation is
much lower if it can be done with what we already have (DNSSEC) rather than
having to drag something like PGP in.

> order, if the file is to be made available?

Sorry I don't quite follow.  What we're suggesting is not a signature over
the file/data, but a hash over the data, which in turn can be signed.

> Because if you basically

For me the mode of transfer is irrelevant.  My goal is to secure the data,
not the transfer.

> MAC signed by the issuer, which permits eg direct binary loadable, or

We're not demanding anything (MAY/SHOULD vs MUST) but what we propose is, as
you say, MAC signed by the issuer.

DW

---

From: George Michaelson <[email-masked]>
Date: Tue, 10 Jul 2018 10:22:58 +1000

Yea, having read things properly and been hit by a cluestick I think
this is good.

* the RR is a digest over canonicalized state

* there is a simple method to take zone, re-canonicalize (its the
DNSSEC order) and check the digest

* since the RR is covered by the ZSK signing, the entire zone is
understood to be in the state the publisher had when they made the
digest.

* if you download a zone file, with this RR, you can re-canonicalize
and check easily.

You have to have a DNSSEC ta over the keys used come what may, but
this looks like a mechanism which given an out of band TA has no
in-band DNS dependency to get a zone and check a zone.

So functionally, Duanes thing is identical in outcome to PGP signing
or other exterior file signatures.

-G

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Jul 2018 12:01:41 +1000

> On 10 Jul 2018, at 10:22 am, George Michaelson <[email-masked]> wrote:
> 

The problem with what is currently there is that it requires the *entire* zone to walked on every dynamic update to recompute the hash.  That has always been the primary objection to SIG(AXFR).

We can do the hashing (and signing) on much smaller increments.

We could sign each RRset that is not already signed (GSIG) in the zone and introduce a glue NSEC like record (GSEC) to prevent those RRsets being removed.

We could hash larger collections of RRsets but smaller than a the whole zone.  That is what XSIG that I proposed earlier does.  It hashes the currently unsigned zone data and prevents its removal from the zone.  I don’t care if it is XSIG or XHASH which is then signed.  Mathematically they are the same.  This mechanism works with OPTOUT and NSEC3 as well as NSEC but does require the unsigned delegations to be hashed if enabled.

Mark

---

From: George Michaelson <[email-masked]>
Date: Tue, 10 Jul 2018 12:10:45 +1000

What I want is the nexus of OOB "file" form zone download and
integrity check which is cheap to implement signer and receiver.

I was on PGP. Duane has taken me to an RR which is a sequenced,
canonicalized digest, which then is under the ZSK sign of the zone.

For the root, it feels doable. For Com, nothing but a
cipher-block-chain model of intermediates is going to scale but a
single file download and integrity check was always going to fail
there.

I know you're talking in-band download: I am targetting out of band
"file" download. Its a model. It works. Its useful. The least
dependencies and easiest path is what I seek, Olafur drove to a new
keying regime and external signatures. Duane has taken me back to "you
can use what you have, if you will canonicalize the file to make the
RR for a digest"

-G

---

From: Warren Kumari <[email-masked]>
Date: Thu, 12 Jul 2018 13:55:35 -0400

> would benefit from having a ZONEMD record inside the zone.

i *seem* to remember something happening with .de a few years back --
IIRC, slaves did a zone transfer, ran out of disk and truncated the
file, and so only had a partial zone file to serve - something like
2/3ds of the .de zone "disappeared". A zone checksum would allow the
nameserver to know that they do not have a full zone file.

My memory is hazy, because I would have expected the AXFR to fail and
the nameserver to just continue using the old zone. Perhaps there was
some other transfer mechanism and it involves restaring the
nameserver? I'm sure someone must remember more detail on this event.

W

> Hugo

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Roy Arends <[email-masked]>
Date: Thu, 12 Jul 2018 19:08:03 +0100

> On 12 Jul 2018, at 18:55, Warren Kumari <[email-masked]> wrote:
> 

https://www.denic.de/en/whats-new/press-releases/article/partial-disturbance-of-the-dns-service-for-de-domains/

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 12 Jul 2018 20:18:55 +0200

> nameserver? I'm sure someone must remember more detail on this event.

It was more complicated then just a full disk and a corrupt AXFR.
It has also to do with moving to new server hardware and the old
servers interfering. I too forgot the details, but Peter Koch might
jump in here.

	jaap

---

From: Florian Weimer <[email-masked]>
Date: Mon, 23 Jul 2018 19:43:36 +0200

The ZONEMD record should contain a size indicator for the zone,
something that allows a receiver to stop downloading if it is clear
that the served zone is too large.  Otherwise, the receiver has to
download the entire zone before it can determine that the hash does
not match.

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 23 Jul 2018 20:40:00 +0000

I wouldn't be opposed to this in principle -- say an RR count field.  

For this to be useful in an unsigned zone then all you need is for the ZONEMD (with RR count field) to be received early in the AXFR.  If it is at the end then this field doesn't help.

For a signed zone, we'd have to think about whether the ZONEMD record should be DNSSEC validated before trusting the RR count field.  If yes then you need the signatures and NSEC* records too, so it becomes sort of complex when you'd be able to trust and check the RR count.

But it seems to me like this is better suited to be a feature of AXFR in general, rather than ZONEMD.

DW

> On Jul 23, 2018, at 10:43 AM, Florian Weimer <[email-masked]> wrote:
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 23 Jul 2018 13:47:35 -0700

The messages on this thread seem to alternate between this being a zone 
hash and a zone signature. There is a pretty large difference between 
the requirements and uses for each.

--Paul Hoffman

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 23 Jul 2018 21:13:33 +0000

> On Jul 23, 2018, at 1:47 PM, Paul Hoffman <[email-masked]> wrote:
> 
> The messages on this thread seem to alternate between this being a zone hash and a zone signature. There is a pretty large difference between the requirements and uses for each.

Thanks for pointing this out.  On the chance that someone is unclear about what we propose in the dns-zone-digest draft (AKA ZONEMD), it is this:

ZONEMD is a hash (message digest) of the zone contents in canonical wire format.  The hash alone provides weak security and the ability to detect unintentional changes or tampering.  It uses the same hashing algorithms that DS uses.

When used with a DNSSEC-signed zone, ZONEMD provides much stronger security guarantees.  The ZONEMD record is signed like all the other records in a zone.

DW

---

From: Florian Weimer <[email-masked]>
Date: Tue, 24 Jul 2018 09:06:22 +0200

> I wouldn't be opposed to this in principle -- say an RR count field.  

That doesn't really bound the amount of transferred data, I think,
because RR size can still vary widely.  I believe something that
counts the hashed bytes would be more helpful and about as easy to
implement.

> For this to be useful in an unsigned zone then all you need is for the
> ZONEMD (with RR count field) to be received early in the AXFR.  If it
> is at the end then this field doesn't help.
>
> For a signed zone, we'd have to think about whether the ZONEMD record
> should be DNSSEC validated before trusting the RR count field.  If yes
> then you need the signatures and NSEC* records too, so it becomes sort
> of complex when you'd be able to trust and check the RR count.

Could you query it before the transfer.

> in general, rather than ZONEMD.

It depends on what you want to achieve with ZONEMD.  If you want to
prevent trivial, but potentially persistent DoS attacks with custom
root servers, you need it in ZONEMD.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Jul 2018 06:17:36 -0700

larger zones cannot afford to recalculate a non-incremental zone hash on 
every single update. is there hope that the zonemd proposal becomes 
incremental before release?

---

From: "John Levine" <[email-masked]>
Date: 24 Jul 2018 10:32:53 -0400

>download the entire zone before it can determine that the hash does

I don't understand why this is a problem that needs solving.  Are we
really attacked by broken zone files with large amounts of added junk,
that are so large that reading them through before discarding them is
a practical performance problem?

I'd think that more likely problems would be that a file was
truncated, or that it was the right size but some entries are
corrupted.

R's,
John

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 26 Jul 2018 05:47:08 +0200

Hi Matt, and other authors,

with my cryptoplumber[1] hat, I am strongly opposed to using SHA-1 and GOST R 34.11-94 for ZONEMD.

It is my understanding, that the specific usage of hashing function in the DS record improves the collision
resistance of the algorithm, because the input data is so small and it has to be a valid DNSKEY record[2].

For ZONEMD, this isn’t true, as you can (in theory) feed the zone with infinite amount of non-DNSSEC-signed
data (GLUEs, delegations) thus making the collision attack feasible.

Thus I believe, the Section 2.1.2 must be changed to disallow usage of algorithms with weakened collision
resistance (and algorithms deprecated by the Russians themselves :). It wouldn’t be enough just to discourage
SHA-1 for creating the ZONEMD, but it needs to be forbidden to use it for validating such record.
I think that new IANA table for ZONEMD must be established, because the security properties of the algorithm
usage are different in DS and ZONEMD records.

Thanks,
Ondrej

1. I would be happy if any real cryptographer would chime in.

2. It doesn’t have to be valid DNSKEY if you just want to cause ruckus, but if you are able to inject invalid DS
    records, you might as well cause damage at other levels of the DNS tree.

--
Ondřej Surý
[email-masked]

> On 23 May 2018, at 17:32, Weinberg, Matt <mweinberg=[email-masked]> wrote:
> 
> Greetings dnsop,
> 
> We’ve posted a new version of draft-wessels-dns-zone-digest.  Of note, this -01 version includes the following changes:
> 
> 	• Warren Kumari and Wes Hardaker have been added as coauthors.
> 	• Several points of clarification in wording and descriptions.
> 	• Removed the requirement to sort by RR CLASS.
> 	• Added a Change Log section.
> 
> Warren and Wes had started on a very similar but unpublished draft, which we should've remembered.  Thanks to them for agreeing to join this document as coauthors.
> We plan to ask for time on the dnsop agenda in Montreal.  Your feedback is welcome and appreciated.    
> 
> Thanks.
> 
> ----
> 
>    A new version of I-D, draft-wessels-dns-zone-digest-01.txt
>    has been successfully submitted by Matt Weinberg and posted to the
>    IETF repository.
> 
>    Name:		draft-wessels-dns-zone-digest
>    Revision:	01
>    Title:		Message Digest for DNS Zones
>    Document date:	2018-05-17
>    Group:		Individual Submission
>    Pages:		13
>    URL:            https://www.ietf.org/internet-drafts/draft-wessels-dns-zone-digest-01.txt
>    Status:         https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/
>    Htmlized:       https://tools.ietf.org/html/draft-wessels-dns-zone-digest-01
>    Htmlized:       https://datatracker.ietf.org/doc/html/draft-wessels-dns-zone-digest
>    Diff:           https://www.ietf.org/rfcdiff?url2=draft-wessels-dns-zone-digest-01
> 
>    Abstract:
>       This document describes a protocol and DNS Resource Record used to
>       provide a message digest over DNS zone data.  In particular, it
>       describes how to compute, sign, represent, and use the message digest
>       to verify the contents of a zone for accuracy and completeness.  The
>       ZONEMD Resource Record type is introduced for conveying the message
>       digest data.
> 
> 
> 
> 
>    Please note that it may take a couple of minutes from the time of submission
>    until the htmlized version and diff are available at tools.ietf.org.
> 
>    The IETF Secretariat
> 
> 
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Jul 2018 21:24:37 -0700

> On Jul 25, 2018, at 20:47, Ondřej Surý <[email-masked]> wrote:
> 
> 

That’s why I suggested already to add the count of the number or unsigned records to the ZONEMD record.

Paul

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 26 Jul 2018 16:37:30 +0000

> On Jul 25, 2018, at 9:24 PM, Paul Wouters <[email-masked]> wrote:
> 
> 

This sounds like a reasonable idea to me.  I'd like to give some thought to whether it should be a count of unsigned records, or all records.  I'll discuss it with the coauthors.

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 26 Jul 2018 16:40:31 +0000

Ondrej,

Thanks, I think thats a fair point.  I was of course hoping to not create yet another IANA registry.

If the ZONEMD RR included a count of records as suggested by Paul Wouters would you then be comfortable
just using the DS hash algorithms?

DW

> On Jul 25, 2018, at 8:47 PM, Ondřej Surý <[email-masked]> wrote:
>

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 26 Jul 2018 18:43:00 +0200

> On 26 Jul 2018, at 18:40, Wessels, Duane <[email-masked]> wrote:
> 
> Ondrej,
> 

That’s probably question you need to ask some cryptographer, so take my opinion with a grain of salt.

If <n> is the number of ZONEMD-covered records, then the probability of collision attack gets higher.  So, unless
I am mistaken, the delegation heavy zones would be especially susceptible to a collision attack.  Does it make
sense?

Ondrej
--
Ondřej Surý
[email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 26 Jul 2018 09:48:52 -0700

On 26 Jul 2018, at 9:43, Ondřej Surý wrote:

> If <n> is the number of ZONEMD-covered records, then the probability 
> of collision attack gets higher.  So, unless
> I am mistaken, the delegation heavy zones would be especially 
> susceptible to a collision attack.  Does it make
> sense?

If the ZONEMD record is signed, the only person who can mount a 
collision attack is the zone owner themselves. If the ZONEMD record is 
unsigned, an attacker can just remove it.

What is the attack you are envisioning?

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 26 Jul 2018 19:25:23 +0200

--
Ondřej Surý
[email-masked]

> On 26 Jul 2018, at 18:48, Paul Hoffman <[email-masked]> wrote:
> 
> If the ZONEMD record is signed, the only person who can mount a collision attack is the zone owner themselves. If the ZONEMD record is unsigned, an attacker can just remove it.

I believe, that’s not true.  The ZONEMD can stay intact while the attacker would modify the unsigned parts of the zone to create a same checksum, but different contents?  He might be targeting just this particular zone and it’s delegation, so everything else is throw-away junk that can be modified.

Ondrej

---

From: Paul Vixie <[email-masked]>
Date: Thu, 26 Jul 2018 11:11:58 -0700

what i mean by incremental is that if a zone remains online and is only 
modified by UPDATE requests, then the identity hash of zone content must 
be updated by each successful update. if it's necessary after each 
update of this kind to iterate through the entire zone to make a new 
zone hash, that's quadratic behaviour ("won't scale").

egads, i may have stumbled upon a use case for block chains.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 26 Jul 2018 17:37:50 -0700

On 26 Jul 2018, at 10:25, Ondřej Surý wrote:

>> collision attack is the zone owner themselves. If the ZONEMD record 
>> is unsigned, an attacker can just remove it.
>
> I believe, that’s not true.  The ZONEMD can stay intact while the 
> attacker would modify the unsigned parts of the zone to create a same 
> checksum, but different contents?  He might be targeting just this 
> particular zone and it’s delegation, so everything else is 
> throw-away junk that can be modified.
>

You didn't answer the last question. It sounds like you want it as a 
signature over the entire zone. If so, then I fully agree that using 
hash algorithms that have known collision attacks is a very bad idea. 
But I also think that using ZONEMD as a strong signature is a bad idea: 
that's what signing algorithms are for.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 Jul 2018 11:32:40 +1000

> On 27 Jul 2018, at 10:37 am, Paul Hoffman <[email-masked]> wrote:
> 
> You didn't answer the last question. It sounds like you want it as a signature over the entire zone. If so, then I fully agree that using hash algorithms that have known collision attacks is a very bad idea. But I also think that using ZONEMD as a strong signature is a bad idea: that's what signing algorithms are for.

ZONEMD and XHASH can both be modelled as a cryptographic hash (NSEC3) or cryptographic hash + signature (RRSIG).  The later will take less space in the zone but more work to update when the signature expires.  Either model will prevent record changes.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 Jul 2018 12:03:52 +1000

> On 27 Jul 2018, at 11:32 am, Mark Andrews <[email-masked]> wrote:
> 
> 
> 

The RRSIG model is the equivalent of a PGP detached signature which signs the hash of the document (or a series of detached signatures in the XHASH case).

For ZONEMD the RRSIG model is better as it requires the consumer to do the cryptographic signature check.

For XHASH the RRSIG model is definitely better for space reasons + it requires the consumer to do the cryptographic signature check (call it XSIG).

In either case I would just use the SIG/RRSIG record format.

Mark

---

From: Davey Song <[email-masked]>
Date: Fri, 27 Jul 2018 10:15:07 +0800

> - It was not really clear exactly what kind of problem this digest
>    tries to solve, especially given that the primarily intended usage
>    is for the root zone, which is DNSSEC-signed with NSEC.
>

It puzzled me as well.

It is said in the document that diffferent from DNSSEC (and NSEC), the zone
digest is for the intergirty of unsigned NS and Glue of the zone. As I
asked in IETF102: why unsigned NS and glue is worth of protecting by
introducing a new RRtype, addtional complexity of degesting and validation.
Is it really necessary for local resolver(or local-root) aware the integity
of NS and glue?  any technical problems if the NS RR and glue are modified
locally?

As to the discussion of re-inventing the wheels, I mean If the problem
statement of zone digest is not a significance of worthing a heavey inband
approach, an lightweight and existing outband approch may be a first option
to consider.

-Davey

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 Jul 2018 12:26:45 +1000

> On 27 Jul 2018, at 12:15 pm, Davey Song <[email-masked]> wrote:
> 
> 
> It is said in the document that diffferent from DNSSEC (and NSEC), the zone digest is for the intergirty of unsigned NS and Glue of the zone. As I asked in IETF102: why unsigned NS and glue is worth of protecting by introducing a new RRtype, addtional complexity of degesting and validation. Is it really necessary for local resolver(or local-root) aware the integity of NS and glue?  any technical problems if the NS RR and glue are modified locally? 

The problem is that when you have every recursive server in the world with a copy of the root zone from “random places” you want to reduce the possible error spaces into manageable chunks when things go wrong which they will.  Being able to verify the contents of the root zone you have are not modified helps.

It also prevents privacy leaks to parties other than the owners of the delegated zones by ensuring the NS and glue addresses records have not been changed.  QNAME minimisation helps with the residual privacy leaks by reducing it to the child zone.

> As to the discussion of re-inventing the wheels, I mean If the problem statement of zone digest is not a significance of worthing a heavey inband approach, an lightweight and existing outband approch may be a first option to consider.. 
> 
> -Davey

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 Jul 2018 12:33:36 +1000

> On 27 Jul 2018, at 12:26 pm, Mark Andrews <[email-masked]> wrote:
> 
> 
> 

Additionally most nameservers treat zone data as fully trusted.  This is reasonable when you are getting data from a “trusted" source.  For the root zone we want servers to be able to get a copy of the zone from a untrusted / less trusted source.

---

From: Steve Crocker <[email-masked]>
Date: Thu, 26 Jul 2018 19:39:29 -0700

The passage below puzzles me.  Why do you want servers to get the root zone from less trusted sources?  And why does the source matter if the zone entries are DNSSEC-signed?

Thanks,

Steve

Sent from my iPhone

> On Jul 26, 2018, at 7:33 PM, Mark Andrews <[email-masked]> wrote:
>

---

From: Shumon Huque <[email-masked]>
Date: Thu, 26 Jul 2018 22:45:12 -0400

On Thu, Jul 26, 2018 at 10:16 PM Davey Song <[email-masked]> wrote:

> It is said in the document that diffferent from DNSSEC (and NSEC), the
> zone digest is for the intergirty of unsigned NS and Glue of the zone. As I
> of NS and glue?  any technical problems if the NS RR and glue are
> modified locally?
>

The ZONEMD digest is over the entire zone, not just the delegation NS and
glue records.

Normally, in order to ensure that secondary servers accurately got a copy
of a zone from the master server, we would use a channel protection
mechanism like TSIG. This is typically needed even if they were no unsigned
data in the zone because authoritative servers do not typically validate
signatures of the data in zones they themselves serve - in theory they
could, but in fact I don't know any implementations that validate RRSIGs
received over zone transfers - they just trust the source and serve the
data. Resolvers validate signatures. Authoritative servers that serve
signed zones trust that they have already have an authentic copy of the
zone.

The problem for wide scale distribution of the root zone, is that
traditional TSIG (without adding a complex key management infrastructure)
doesn't scale. Earlier in this thread, I had proposed that SIG(0) could be
a scalable solution to this problem, but it has some limitations, and Duane
has argued that the full zone signature is a better solution. I'm not
opposed to this, but I think Mark Andrew's XHASH proposal is worth thinking
through also.

Even if the local-root-zone resolvers were modified to validate signatures
of signed RRsets in the zone, if a MITM attacker fed them bogus glue, to
recover from this, they would need operator intervention to manually
retransfer the zone. This doesn't strike me as a robust operational
configuration.

--Shumon.

---

From: Steve Crocker <[email-masked]>
Date: Thu, 26 Jul 2018 19:52:53 -0700

Let me play Candide and stumble into this naively.  If we’re imagining very
wide spread distribution of the root zone, say 100,000 or 1,000,000 local
copies distributed twice a day, I would expect the evolution of a set of
trusted sources and the use of some existing secure transport protocol to
protect the transmission.  No new protocol or data types, just a way of
finding the address of one more trusted sources.  And the existing set of
root servers seems like a perfectly good set of trusted sources.

Steve

---

From: Shumon Huque <[email-masked]>
Date: Thu, 26 Jul 2018 22:59:53 -0400

On Thu, Jul 26, 2018 at 10:53 PM Steve Crocker <[email-masked]> wrote:

> Let me play Candide and stumble into this naively.  If we’re imagining
> very wide spread distribution of the root zone, say 100,000 or 1,000,000
> local copies distributed twice a day, I would expect the evolution of a set
> of trusted sources and the use of some existing secure transport protocol
> to protect the transmission.  No new protocol or data types, just a way of

Hi Steve,

Yes, I've made precisely the same argument previously in this very thread:

https://www.ietf.org/mail-archive/web/dnsop/current/msg23094.html

"> In my mind, the main compelling use case is secure distribution of the
> root zone at scale to anyone on the Internet. For that, I'd bet that
> many consumers would be quite okay with a channel security mechanism
> to a "trusted" root zone operator, whatever that mechanism is (TSIG,
> SIG(0), TLS, HTTPS, etc) as long as it could be done efficiently and
> at scale. A full zone signature from the zone publisher/signer is
> ultimately more secure of course. But if the security model is
> satisfied by trust in RSOs, then that isn't needed."

At the moment, some WG members feel that full zone signature is more secure
and needed. I'm not convinced (on the "needed"), but don't feel strongly
enough to be opposed either.

Shumon.

---

From: Davey Song <[email-masked]>
Date: Fri, 27 Jul 2018 10:59:53 +0800

>
> The problem is that when you have every recursive server in the world with
> a copy of the root zone from “random places” you want to reduce the
> possible error spaces into manageable chunks when things go wrong which
> they will.  Being able to verify the contents of the root zone you have are
> not modified helps.
>

Generaly speaking it is ture for any file replication. But it is not
relevent with DNS context. And your arguement of potential privacy issues
seems reasonable to me even though I know some cases people intentionaly
edit the NS and glue of root zone for preventing privacy leaks :p

Davey

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 Jul 2018 13:06:45 +1000

> On 27 Jul 2018, at 12:39 pm, Steve Crocker <[email-masked]> wrote:
> 
> The passage below puzzles me.  Why do you want servers to get the root zone from less trusted sources?

1) to spread load.
2) not all recursive servers have direct access to authoritative sources.  Some times they need to go through intermediaries.  The same will be true with transfers of the root zone.

>  And why does the source matter if the zone entries are DNSSEC-signed?

Steve please go and re-read the parts you cut out when quoting the previous message.  It gave several reasons.

Also please look at what is and isn’t signed in a zone and think about what can be done when you can change the unsigned parts.

Also think about what can be done when you change the signed parts but don’t individually verify the RRsets but rather just trust the zone content.

I have a local copy of the root zone.  It lives in a seperate view which is not accessed directly by clients  The name server validate its contents when performing recursive lookups on behalf of clients.  Such configurations are complicated and error prone.  It also doesn’t remove potential privacy leaks.

Having a way to verify the entire zone’s contents without having to verify every RRset individually after each zone transfer would make running such configurations easier.  It also removes threats that DNSSEC alone does not remove.

---

From: Davey Song <[email-masked]>
Date: Fri, 27 Jul 2018 11:24:33 +0800

The draft says zone digest is not for protecting zone transmition. IMHO,
the treat model is  MITM attack by malicious editing on on-disk data (NS
and glue especially) and server the new zone to end user. DNS digest
intends to enable end users (resolvers)  automatically detect the
modifation ( and drop the zone?).

Davey

On Fri, 27 Jul 2018 at 11:00, Shumon Huque <[email-masked]> wrote:

> At the moment, some WG members feel that full zone signature is more
> secure and needed. I'm not convinced (on the "needed"), but don't feel
> strongly enough to be opposed either.
>
> Shumon.
>
>

---

From: Shumon Huque <[email-masked]>
Date: Thu, 26 Jul 2018 23:35:27 -0400

> that's what signing algorithms are for.

I believe Ondrej is correct.

If we use hash algorithms that are vulnerable to collision attacks, then an
attacker might be able to produce a modified zonefile that hashes to the
same ZONEMD value (and thus the ZONEMD RRSIG).

Signing the whole zone directly isn't really much different. All DNSSEC
signature algorithms sign a hash of their input, so again we'd be signing a
hash of the full zone. So we should only be using cryptographic hash
functions not (yet) known to be vulnerable to collision attacks. So SHA256
or better.

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 26 Jul 2018 23:49:39 -0400

> modifation ( and drop the zone?).

That is one possible threat, but I think it's pretty clear from mailing
list discussion that verifying that the zone is transmitted correctly is
one of the key use cases (whether that is post zone transfer verification,
or out-of-band delivery):

   "It allows a receiver of
   the zone file to verify the zone file's authenticity, especially when
   used in combination with DNSSEC.  This technique makes the message
   digest a part of the zone file itself, allowing anything to verify
   the zone file as a whole, no matter how it is transmitted."

Shumon.

---

From: Evan Hunt <[email-masked]>
Date: Fri, 27 Jul 2018 04:04:06 +0000

On Fri, Jul 27, 2018 at 11:24:33AM +0800, Davey Song wrote:
> The draft says zone digest is not for protecting zone transmition.

Where did it say that? I didn't notice it.

> IMHO, the treat model is  MITM attack by malicious editing on on-disk
> data (NS and glue especially) and server the new zone to end user. DNS
> digest intends to enable end users (resolvers)  automatically detect the

I don't think that's entirely correct.

Normal resolvers don't need to transfer in a full zone; they just send
queries for individual records and validate RRSIGs. There's no zone for
for it to check against ZONEMD, or for it to drop if the check fails.

However, a resolver configured with a local copy of the root zone as in RFC
7706 *does* contain the full zone, and has to get it somehow.  Perhaps it
gets it via AXFR, perhaps via some out-of-band mechanism. Either way, once
the local copy is obtained, ZONEMD allows it to be verified.

So, yes, ZONEMD does protect zone transmission. It does so regardless of
channel - TLS, AXFR/IXFR, sneakernet, whatever.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Davey Song <[email-masked]>
Date: Fri, 27 Jul 2018 12:13:41 +0800

> Where did it say that? I didn't notice it.

 I mean zone digest is not for zone transimition with channel security. On
page 4, the authors compare zone digest and Channel security.

   Unfortunately, the protections provided by these channel security
   techniques are ephemeral and are not retained after the data transfer
   is complete.  They can ensure that the client receives the data from
   the expected server, and that the data sent by the server is not
   modified during transmission.  However, they do not guarantee that
   the server transmits the data as originally published, and do not
   provide any methods to verify data that is read after transmission is
   complete.  For example, a name server loading saved zone data upon
   restart cannot guarantee that the on-disk data has not been modified.
   For these reasons, it is preferable to secure the data itself.

 Davey

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 Jul 2018 14:18:46 +1000

Davey,
	just because A => B, it doesn’t mean that !B => !A.  Your
        analysis is flawed.
Mark

> On 27 Jul 2018, at 2:13 pm, Davey Song <[email-masked]> wrote:
> 
> 
> 
>  I mean zone digest is not for zone transimition with channel security. On page 4, the authors compare zone digest and Channel security.
>

---

From: Evan Hunt <[email-masked]>
Date: Fri, 27 Jul 2018 04:34:33 +0000

On Fri, Jul 27, 2018 at 02:18:46PM +1000, Mark Andrews wrote:
> 	just because A => B, it doesn’t mean that !B => !A.

(... it does mean that, actually.)

>  I mean zone digest is not for zone transimition with channel security. On page 4, the authors compare zone digest and Channel security.

I think this is meant to explain why channel security mechanisms like
TLS have limitations, and ZONEMD can do even more.

But that doesn't mean the use cases for ZONEMD is restricted to the ones
not handled by TLS.  You can use ZONEMD with AXFR, too.

---

From: Tony Finch <[email-masked]>
Date: Fri, 27 Jul 2018 12:17:34 +0100

> egads, i may have stumbled upon a use case for block chains.

Ah, the obvious solution is to deprecate zone files and just ship update
journals instead!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire: Southeasterly 5 to 7, occasionally 4 in
North Utsire. Moderate, occasionally rough in Viking. Thundery showers at
first, becoming fair. Good, occasionally poor at first.

---

From: Jim Reid <[email-masked]>
Date: Fri, 27 Jul 2018 12:28:03 +0100

> On 27 Jul 2018, at 12:17, Tony Finch <[email-masked]> wrote:
> 

Why not go for distributed hash tables? :-)

Says he running away to watch the fireworks from a safe distance...

---

From: Shumon Huque <[email-masked]>
Date: Fri, 27 Jul 2018 07:51:57 -0400

> Says he running away to watch the fireworks from a safe distance...

(Not  to descend into another rathole but ..)

Actually Jim, if things are headed in the direction of "protecting user's
privacy" by funneling DNS queries over HTTPS to a small set of CDN
operators run by unregulated private corporations, I think the Internet
community needs to seriously look at more decentralized solutions to name
resolution, and more radical approaches, even DHTs, should be on the table
perhaps ..

Shumon.

---

From: Bob Harold <[email-masked]>
Date: Fri, 27 Jul 2018 10:57:45 -0400

On Thu, Jul 26, 2018 at 11:07 PM Mark Andrews <[email-masked]> wrote:

> 2) not all recursive servers have direct access to authoritative sources.
> Some times they need to go through intermediaries.  The same will be true
> with transfers of the root zone.
>

Maybe I am wrong, but having lots of servers all around the world asking
for the same update at the same time looks like a good place to use
bittorrent.  (Is that reasonable?)  So the 'sources' will be untrusted, and
we do need some way to verify the resulting file that we get.

I like the XHASH idea, it seems to reduce the work required on each
update.  But I would be ok with ZONEMD also.

-- 
Bob Harold

> Steve please go and re-read the parts you cut out when quoting the
> previous message.  It gave several reasons.
>
> Also please look at what is and isn’t signed in a zone and think about
> what can be done when you can change the unsigned parts.
>
> Also think about what can be done when you change the signed parts but
> don’t individually verify the RRsets but rather just trust the zone content.
>
> I have a local copy of the root zone.  It lives in a seperate view which
> is not accessed directly by clients  The name server validate its contents
> when performing recursive lookups on behalf of clients.  Such
> configurations are complicated and error prone.  It also doesn’t remove
> potential privacy leaks.
>
> Having a way to verify the entire zone’s contents without having to verify
> every RRset individually after each zone transfer would make running such
> configurations easier.  It also removes threats that DNSSEC alone does not
> remove.
>
> > Thanks,
> >
> > Steve
> >
> > Sent from my iPhone
> >
> >> Additionally most nameservers treat zone data as fully trusted.  This
> is reasonable when you are getting data from a “trusted" source.  For the
> root zone we want servers to be able to get a copy of the zone from a
> untrusted / less trusted source.
>
> --
> Mark Andrews, ISC

---

From: "John Levine" <[email-masked]>
Date: 27 Jul 2018 11:37:02 -0400

In article <CABf5zvKnV_YodJSE3UcEXVfJaew0enCzDg_T7Ni=D8xS=[email-masked]> you write:
>-=-=-=-=-=-

I was with you until the last sentence.  This is about as ideal an
application for bittorrent as one can imagine.  No new protocol, but
it would be nice to have some way to validate it.

I also observe that about half of the roots allow AXFR and half don't.
It might be interesting to ask why they made those respective choices.

R's,
Pangloss

---

From: 神明達哉 <[email-masked]>
Date: Fri, 27 Jul 2018 11:59:57 -0700

At Fri, 27 Jul 2018 10:59:53 +0800,
Davey Song <[email-masked]> wrote:

> relevent with DNS context.

Right, so I think one main question is why the root DNS zone case is
so special that a protocol extension is justified.  Personally, I'm
not yet fully convinced about it through the discussion so far.  As
several other people seem to be persuaded, however, maybe I'm too wary
just because of my hat of handling eventual "named triggers an
assertion failure after zone transfer for some bogus zone digest"
CVEs.  But at the same time, if my sense of the wg's take on the "DNS
camel" discussion is correct, I think we (WG) should require a higher
level of justification for new protocol features.  Again, personally,
I don't yet think draft-wessels-dns-zone-digest has passed this test.

--
JINMEI, Tatuya

---

From: Warren Kumari <[email-masked]>
Date: Fri, 27 Jul 2018 16:43:44 -0400

On Fri, Jul 27, 2018 at 3:02 PM 神明達哉 <[email-masked]> wrote:
> level of justification for new protocol features.

This can, but does not have, to be built into the nameserver itself.

As examples, Shane Kerr has created
https://github.com/shane-kerr/ZoneDigestHackathon
and Duane has created https://github.com/verisign/ldns-zone-digest
Both of these can be used as external utilities to validate a zone file.

I'd be perfectly happy doing something like:
'dig AXFR . @b.root-servers.net > root.zone (or wget
https://www.internic.net/domain/root.zone )
ldns-zone-digest -v . root.zone
if [ $? -eq 0 ]
  then
    `rndc reload .`
  else
    send_alert_critical.sh "Local root zone issue" "Panic\! Unable to
load new root zone"
fi'

(obviously with more error checking :-))

I'm also somewhat more paranoid than most - I'd personally also like
to be able to do something like:
for file in *
  do
    ldns-zone-digest -v $file $file.zone
      if [ $? -ne 0 ]
        then
          echo "${file} has been corrupted. Aborting..."
          exit 1
        fi
   done

in my init scripts.

I also used to host a zone for a friend who doesn't run his own
nameserver. He would email the the zonefile whenever he made changes,
and I would copy and paste it into a file[0] - it sure would have been
nice to be able to run something like 'named-checkzone foo foo' and
make sure I'd copied and pasted the whole thing correctly...

W
[0]: He wasn't really the sort of person I wanted to give a shell on
my machine to :-)

> Again, personally,

---

From: 神明達哉 <[email-masked]>
Date: Fri, 27 Jul 2018 14:22:50 -0700

At Fri, 27 Jul 2018 16:43:44 -0400,

> This can, but does not have, to be built into the nameserver itself.

True, and I might feel much better if the draft said "name server
implementations MUST NOT compute or validate the zone digest
in their code":-).  More seriously, my concern with the "hat" wouldn't
be addressed simply because it can be implemented outside of a name server
implementation.  In fact, I can see it'll eventually be included in
code base I'll have to maintain if it's officially adopted and
published.  On the other hand, if we're okay with an out-of-band
implementation (independently from whether we like it in a name
server), then I guess it will become less distinguishable from
out-of-band digest approaches.  Either way it requires the operators
to use an additional tool, and it's therefore more operationally
costly, error prone, or easier to be ignored/forgotten.

--
JINMEI, Tatuya

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 28 Jul 2018 04:25:39 -0400

> incremental before release?
As a user of the DNS, this comment is very relevant to my needs.

As a co-chair of DNSOP, I think the authors  are being very narrow in their
use case.

Tim

---

From: Florian Weimer <[email-masked]>
Date: Sat, 28 Jul 2018 14:32:04 +0200

> a practical performance problem?

It's a practical problem if you want to update the zone from a
completely untrusted source.  I assumed that was in scope for ZONEMD.

On the other hand, clients will likely have a pretty good idea for the
size of the zone, so they could transfer it twice: Once for computing
the authenticated size, in hashing-only mode, once they realize that
the size of the new version exceeds the current version by 15% (or
so).  And after the authenticated size is known, they download the new
version for real.  This complexity could be avoided if the server
simply told how many bytes have been hashed in the digest.

---

From: "John R Levine" <[email-masked]>
Date: 28 Jul 2018 11:08:42 -0400

>>> not match. ...

> size of the zone, so they could transfer it twice: ...

Now I'm really confused.  To avoid downloading the whole zone you download 
it twice?

Could you explain in simple terms why you can't download the zone, check 
the digest and signature, and either use it or discard it?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Florian Weimer <[email-masked]>
Date: Sat, 28 Jul 2018 17:47:37 +0200

> the digest and signature, and either use it or discard it?

A malicious server might never stop sending data, or claim that the
transfer is ridiculously large.  If the zone digest does not include
information about the amount of data, this can only be detected after
the server ended transmission, at which time the ZONEMD digest can be
compared.  But at this point, the client may already have filled its
storage with garbage data, unless the double transfer trick is used.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 28 Jul 2018 08:55:34 -0700

Another reason for an rr count number in the rrtype. 

Sent from my phone

> On Jul 28, 2018, at 08:47, Florian Weimer <[email-masked]> wrote:
> 
> * John R. Levine:
>

---

From: Florian Weimer <[email-masked]>
Date: Sat, 28 Jul 2018 18:04:46 +0200

> Another reason for an rr count number in the rrtype. 

The typical RR size is perhaps 1/300 of the protocol maximum (much
less without DNSSEC), so this is only sufficient for small zones.

---

From: "John R Levine" <[email-masked]>
Date: 28 Jul 2018 12:13:13 -0400

> storage with garbage data, unless the double transfer trick is used.

I realize that hypothetically a malicious server could send you a large 
file of garbage.  But that can happen any time you downlaod a file from 
anywhere.  It doesn't strike me as something that needs special hackery 
for this rather specific case.

On the other hand, I don't see any particular reason that the ZONEMD 
couldn't have a field for the number of records, and it goes at the apex 
of the zone so you'd expect to find it near the front of the file.

Regards,

---

From: Ondřej Surý <[email-masked]>
Date: Sat, 28 Jul 2018 21:43:13 +0200

@ISC, we have been discussing this since we started implementing RZ local copy and it’s not that simple.

There are at least two problems with BitTorrent:

a) the hash has to be independent to zone, so either the hash has to reside outside of the root zone, or the root zone file would have to be reconstructed with “the torrent hash” and “the torrent data”; generally you would want the hash to be signed, so the TORRENT RR + RRSIG would have to be distributed outside of the data received via BitTorrent

b) to be effective, most of the peers would have to seed, and I am not sure if the places that would benefit the most would be the places where operators would be willing to seed

Ondrej
--
Ondřej Surý — ISC

> On 27 Jul 2018, at 16:57, Bob Harold <[email-masked]> wrote:
> 
> 
> Maybe I am wrong, but having lots of servers all around the world asking for the same update at the same time looks like a good place to use bittorrent.  (Is that reasonable?)  So the 'sources' will be untrusted, and we do need some way to verify the resulting file that we get..
> 
> I like the XHASH idea, it seems to reduce the work required on each update.  But I would be ok with ZONEMD also.
> 
> -- 
> Bob Harold
>

---

From: tjw ietf <[email-masked]>
Date: Sat, 28 Jul 2018 15:57:53 -0400

Oh folks like my employer where half of the security teams scream and say no, and the other half want to see to collect threat intelligence information. 

From my high tech gadget

> On Jul 28, 2018, at 15:43, Ondřej Surý <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 28 Jul 2018 17:58:05 -0400

In article <[email-masked]> you write:
>a) the hash has to be independent to zone, so either the hash has to reside outside of the root zone, or the root zone file would
>have to be reconstructed with “the torrent hash” and “the torrent data”; generally you would want the hash to be signed,
>so the TORRENT RR + RRSIG would have to be distributed outside of the data received via BitTorrent

I'm confused again.  Why couldn't the hash RR and sig be in the zone
just like any other record in the zone?

R's,
John

---

From: Ondřej Surý <[email-masked]>
Date: Sun, 29 Jul 2018 06:35:20 +0200

The way BitTorrent works, it’s basically a Merkle tree over the chunks. So, you need to compute the main hash over the zone data.

Maybe there’s a smart way to compute hash over the data that includes that hash, but my poor brain thinks it would break the Matrix (or at least the hashing function).

Therefore either you need to exclude the data that changes (hash and its RRSIG) when computing the hash for the BitTorrent and the receiving side would have to reassemble this. Or you would need OOB mechanism to distribute the hash (different part of the tree, CDN, ...).

Ondřej 
--
Ondřej Surý — ISC

> On 28 Jul 2018, at 23:58, John Levine <[email-masked]> wrote:
>

---

From: "John R Levine" <[email-masked]>
Date: 29 Jul 2018 00:50:18 -0400

> Therefore either you need to exclude the data that changes (hash and its RRSIG) when computing the hash for the BitTorrent and the receiving side would have to reassemble this. Or you would need OO…

Of course you exclude the hash record from the hash.  Look at the way we 
do DKIM signatures -- the header hash includes all the headers including 
the signature header, but it pretends there's no hash field in it.

I'm also thinking the hash wouldn't need to include the RRSIG records, 
since those are mechanically derived from the underlying records and the 
ZSK.

Regards,

---

From: Ondřej Surý <[email-masked]>
Date: Sun, 29 Jul 2018 10:55:31 +0200

Mail headers doesn’t have NSEC records.  Also any operation where you need to reconstruct the file by combining bits from different places/channels is prone to errors.

You need to know the hash is valid before you start the download. Therefore the hash has to be signed.

O.
--
Ondřej Surý — ISC

On 29 Jul 2018, at 06:50, John R Levine <[email-masked]> wrote:

> Of course you exclude the hash record from the hash.  Look at the way we do DKIM signatures -- the header hash includes all the headers including the signature header, but it pretends there's no hash field in it.
> 
> I'm also thinking the hash wouldn't need to include the RRSIG records, since those are mechanically derived from the underlying records and the ZSK.
> 
> 
> Regards,

---

From: "John Levine" <[email-masked]>
Date: 29 Jul 2018 11:50:13 -0400

In article <[email-masked]> you write:
>Mail headers doesn’t have NSEC records.  Also any operation where you need to reconstruct the file by combining bits from
>different places/channels is prone to errors.
>

We must have some basic difference in our mental models here.  Mine is:

1.  Download the zone from wherever.

2.  Sort the records and compute the hash.

3.  Check that the hash you computed matches the one in the ZONEMD.

4.  Check that the DNSSEC signature of the ZONEMD is valid.

If all that works, use the zone.  If not, throw it away.

What am I missing?

---

From: Steve Crocker <[email-masked]>
Date: Sun, 29 Jul 2018 09:19:16 -0700

It feels like this discussion is based on some peculiar and likely incorrect assumptions about the evolution of root service.  Progression toward hyper local distribution of the root zone seems like a useful and natural sequence.  However, the source of the copies of the root zone will almost certainly remain robust and trusted.  The current system has evolved carefully over a very long period of time.  Recursive resolvers are configured with a hints file and start up fetching the current set of root servers.  (This is the priming process.).  The evolution that’s needed as more and more recursive resolvers fetch complete copies of the root zone is simply the strengthening of the distribution process.

The root server operators have been spending quite a bit of time thinking about the future.  One important result is the recent RSSAC report, RSSAC 037, 
https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf .  This focuses on possible changes in their governance and doesn’t speak directly to the issues here, but it’s part of a larger process of looking at the future.

It seems to me very reasonable for this group  to say what you would like in the way of an evolving root service and distribution system.

Steve

---

From: Joe Abley <[email-masked]>
Date: Sun, 29 Jul 2018 11:50:41 -0700

On Jul 29, 2018, at 12:19, Steve Crocker <[email-masked]> wrote:

> It feels like this discussion is based on some peculiar and likely incorrect assumptions about the evolution of root service.  Progression toward hyper local distribution of the root zone seems like a useful and natural sequence.  However, the source of the copies of the root zone will almost certainly remain robust and trusted.

I think you need to be more clear what you mean by "source".

If you mean the original entity that constructs and first makes
available the root zone (e.g. the root zone maintainer in the current
system) then what you say seems uncontentious.

If what you mean is "the place that any particular consumer if the
root zone might have found it" then I think you need to show your
working.

Resolvers currently prime from a set of trusted servers (albeit over
an insecure transport without authentication, so we could quibble
about what "trusted" means even there) but it's not obvious to me that
this is a necessary prerequisite for new approaches.

If I have a server sitting next to me that has a current and accurate
copy of the root zone and I am able to get it from there and assess
the accuracy of what I receive autonomously, why wouldn't I?

Joe

---

From: Steve Crocker <[email-masked]>
Date: Sun, 29 Jul 2018 12:09:35 -0700

Joe,

As an individuals, you, I, or anyone else, can do whatever we like, of
course.  On the other hand, as system designers we presumably look at the
overall system and try to put in place an operational structure that
anticipates and meets the likely needs of the users.

The present and long-standing system provides the recursive resolvers with
well-oiled and highly effective solutions to (a) finding the root servers
and (b) getting highly reliable and highly responsive answers from them.
It seems to me reasonable and reasonably easy to sustain these attributes
as we evolve toward downloading the entire root zone instead of individual
pieces of it.  And by "evolution" we're necessarily talking about a lengthy
period of hybrid operation.  There will likely be a growing set of
recursive resolvers downloading the full root zone and but there will
certainly be a very large set of recursive resolvers that continue to
operate in the current model.  Even if there were to be an aggressive push
toward hyper local root service, the existing service would have to remain
as is for a long time.  And by "a long time" I'm guessing ten years is not
enough, so I suspect it will be twenty years before one can imagine the
current root service reaching twilight.

The heated concern of several years ago about the potential size of the
root zone is behind us, I hope.  The root zone is not going to grow
exponentially.  The whole zone will be in the single megabyte range, I
think.  (Caution: I haven't looked at the actual size.  Apologies if I am
off a bit.  But the overall point is still right.  Another round or so of
gTLDs might double or even triple the current size of the root zone, but it
will not grow by even one order of magnitude and certainly not by multiple
orders of magnitude.)

Distribution of a megabyte or even a few megabytes to, say, a million
recursive resolvers twice a day is a relatively modest endeavor on today's
Internet.  If there are going to be problems, I suspect they won't be
related to ad hoc fetching of the root zone from random untrusted sources.

Steve

On Sun, Jul 29, 2018 at 11:50 AM, Joe Abley <[email-masked]> wrote:

> > It feels like this discussion is based on some peculiar and likely
> incorrect assumptions about the evolution of root service.  Progression
> toward hyper local distribution of the root zone seems like a useful and
> natural sequence.  However, the source of the copies of the root zone will
> almost certainly remain robust and trusted.
>

---

From: Joe Abley <[email-masked]>
Date: Sun, 29 Jul 2018 15:44:38 -0400

Hi Steve,

On Jul 29, 2018, at 15:09, Steve Crocker <[email-masked]> wrote:

> As an individuals, you, I, or anyone else, can do whatever we like, of course.  On the other hand, as system designers we presumably look at the overall system and try to put in place an operational structure that anticipates and meets the likely needs of the users.

Agreed!

> The present and long-standing system provides the recursive resolvers with well-oiled and highly effective solutions to (a) finding the root servers and (b) getting highly reliable and highly responsive answers from them.

This is true. However, there are some disadvantages of the current system that are worth thinking about when we consider alternatives, such as the privacy implications of having all resolvers call home to a set of well-known servers and the aggregate cost of engineering and operations that has gone into making the root system as resilient as it is.

I have spoken in the past in opposition to the idea that slaving the root zone on resolvers was a desirable end-state; I think it leaves operational gaps that we should want to fill. Being able to validate the contents of the zone and have software react appropriately (without human operator intervention) when zone data is found to be stale or inaccurate obviates many of my concerns.

Perhaps there is a future where the root server system was preserved only to serve legacy clients, whilst more modern software had a diversity of options in addition to that fall-back.

I think the root zone is a convenient starting point for these kinds of discussions, but I think the scope could be wider. Maybe one day the DNS protocol (for all zones, not just the root zone) is only comonly used for communications between stub and resolver, where we have the deployed base with the longest tail, and where capacity planning and attack resistance is a different kind of problem because all your traffic generators are on-net. Perhaps the database problem of replicating authoritative data into resolver caches is solved in different ways.

It would be nice if end-users didn't have to rely upon authoritative servers being up in order to resolve names; it would be nice if there wasn't a small set of targets against which the next memcached-scale attack could be used to take us back to 21 October 2016; it would be nice if the integrity of the naming scheme didn't ultimately rely upon the deployment of BCP38.

If such a mechanism relied upon DNSSEC to ensure integrity of data in the absence of plausible channel authentication, availability of zones might be aligned with DNSSEC deployment, which would give the Alexa 500 a(nother) reason to sign their zones.

There are lots of things to think about here. I don't think clinging to the status quo in terms of infrastructure or institutions is necessarily a good idea, although I do agree with the idea of preserving legacy compatability and incremental change.

Joe

---

From: Steve Crocker <[email-masked]>
Date: Sun, 29 Jul 2018 12:59:21 -0700

Joe,

Thanks.  You've mentioned several things tagged with "it would be nice to
have."  Each of these has both (a) one or more assumptions about a problem
that seeking to be addressed and (b) the implication of a fairly massive
architectural change.  These need a deeper and better organized discussion
than can be done on this list.  This is really IAB territory or something
similar, in my opinion, and the starting point is a careful delineation of
the problems before we engage in specific solutions.  Your experience,
perceptions and judgments are top notch, but it will take time and work to
get everyone else on the same page.  (Or not.)

Meanwhile, there is already an evolution toward local service of the root
zone.  It seems to be there are two relevant threads to pursue.  One is how
best to support it, and the other, picking up on your point, is to
understand what problems, defects, etc. there might be as more and more
recursive resolvers start to serve the root zone.

Speaking for myself, I'm not opposed, in principle, to thinking about fresh
designs and radical changes where it's appropriate.  For example, I have
made comments in the past and will be making more comments in the future
about the whois system.  But with respect to the evolution of the root
service, I'm not in agreement that we should be entangling it with the much
larger architectural issues you're raising.

Steve

On Sun, Jul 29, 2018 at 12:44 PM, Joe Abley <[email-masked]> wrote:

> > The present and long-standing system provides the recursive resolvers
> with well-oiled and highly effective solutions to (a) finding the root
> servers and (b) getting highly reliable and highly responsive answers from
> them.
>
> This is true. However, there are some disadvantages of the current system
> that are worth thinking about when we consider alternatives, such as the
> privacy implications of having all resolvers call home to a set of
> well-known servers and the aggregate cost of engineering and operations
> that has gone into making the root system as resilient as it is.
>
> I have spoken in the past in opposition to the idea that slaving the root
> zone on resolvers was a desirable end-state; I think it leaves operational
> gaps that we should want to fill. Being able to validate the contents of
> the zone and have software react appropriately (without human operator
> intervention) when zone data is found to be stale or inaccurate obviates
> many of my concerns.
>
> Perhaps there is a future where the root server system was preserved only
> to serve legacy clients, whilst more modern software had a diversity of
> options in addition to that fall-back.
>
> I think the root zone is a convenient starting point for these kinds of
> discussions, but I think the scope could be wider. Maybe one day the DNS
> protocol (for all zones, not just the root zone) is only comonly used for
> communications between stub and resolver, where we have the deployed base
> with the longest tail, and where capacity planning and attack resistance is
> a different kind of problem because all your traffic generators are on-net.
> Perhaps the database problem of replicating authoritative data into
> resolver caches is solved in different ways.
>
> It would be nice if end-users didn't have to rely upon authoritative
> servers being up in order to resolve names; it would be nice if there
> wasn't a small set of targets against which the next memcached-scale attack
> could be used to take us back to 21 October 2016; it would be nice if the
> integrity of the naming scheme didn't ultimately rely upon the deployment
> of BCP38.
>
> If such a mechanism relied upon DNSSEC to ensure integrity of data in the
> absence of plausible channel authentication, availability of zones might be
> aligned with DNSSEC deployment, which would give the Alexa 500 a(nother)
> reason to sign their zones.
>
> There are lots of things to think about here. I don't think clinging to
> the status quo in terms of infrastructure or institutions is necessarily a
> good idea, although I do agree with the idea of preserving legacy
> compatability and incremental change.
>
>
> Joe

---

From: Evan Hunt <[email-masked]>
Date: Sun, 29 Jul 2018 21:03:44 +0000

> Therefore the hash has to be signed.

Before you *start* the download? Or before you use what you downloaded?

---

From: Florian Weimer <[email-masked]>
Date: Sun, 29 Jul 2018 23:07:16 +0200

> for this rather specific case.

A lot of other updaters use HTTPS, which does not have this issue if
the terminating party is also the source of the data.  Those that do
not use other mechanisms.  There is quite a bit of previous work in
this area (see <https://theupdateframework.github.io/> for specific
take on this subject), and the current ZONEMD draft does not
acknowledge this, even though its goals are broadly similar.

---

From: Joe Abley <[email-masked]>
Date: Sun, 29 Jul 2018 17:32:14 -0400

Hi Steve,

I fully agree that the kinds of things I was waving my hands about are science projects at best, and so far from ready for informed standardisation in dnsop that it seems silly even typing that phrase.

However, you were speculating about the future in your reaction to some of the commentary here, and inferring that the draft under discussion (or some of the discussion surrounding it) was pointing in a silly direction.

I was just trying to illustrate that there are more possible directions. Many of them may well be silly, but it's a little early to pass judgement, I think.

Joe

> On Jul 29, 2018, at 15:59, Steve Crocker <[email-masked]> wrote:
> 
> Joe,
> 
> Thanks.  You've mentioned several things tagged with "it would be nice to have."  Each of these has both (a) one or more assumptions about a problem that seeking to be addressed and (b) the implication of a fairly massive architectural change.  These need a deeper and better organized discussion than can be done on this list.  This is really IAB territory or something similar, in my opinion, and the starting point is a careful delineation of the problems before we engage in specific solutions.  Your experience, perceptions and judgments are top notch, but it will take time and work to get everyone else on the same page.  (Or not.)
> 
> Meanwhile, there is already an evolution toward local service of the root zone.  It seems to be there are two relevant threads to pursue.  One is how best to support it, and the other, picking up on your point, is to understand what problems, defects, etc. there might be as more and more recursive resolvers start to serve the root zone.
> 
> Speaking for myself, I'm not opposed, in principle, to thinking about fresh designs and radical changes where it's appropriate.  For example, I have made comments in the past and will be making more comments in the future about the whois system.  But with respect to the evolution of the root service, I'm not in agreement that we should be entangling it with the much larger architectural issues you're raising.
> 
> Steve
> 
>

---

From: "John R Levine" <[email-masked]>
Date: 29 Jul 2018 18:32:35 -0400

>> file of garbage. ...

> the terminating party is also the source of the data. ...

Doesn't that assume that the other server will never be compromised?  I 
realize that trying to guess how the other end might do bad things is a 
rathole, which is why I don't want try to invent anything beyond what we 
already have for dealing with downloaded files.

It seems to me that the clever bit about ZONEMD is that it uses the 
existing DNSSEC keys so you don't have to invent a new key management 
scheme.

Regards,

PS: I agree that a paragraph or two about other ways that people 
distribute zone files wouldn't hurt.

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 30 Jul 2018 09:19:14 +0200

I know some people have 40Gbps at mothers house, but for general usefulness you want to prevent downloading fake (or otherwise invalid) zone before you start downloading it.

Especially, it might be very harmful if the client could be tricked into downloading any data distributed via torrent. You don’t want SWAT unit knocking down your door because your nameserver downloaded Universal Declaration of Human Rights.

Ondřej 
--
Ondřej Surý — ISC

> On 29 Jul 2018, at 23:03, Evan Hunt <[email-masked]> wrote:
>

---

From: Tony Finch <[email-masked]>
Date: Mon, 30 Jul 2018 14:17:31 +0100

John R Levine <[email-masked]> wrote:
>
> I'm also thinking the hash wouldn't need to include the RRSIG records, since
> those are mechanically derived from the underlying records and the ZSK.

If you omit the RRSIGs from the hash, you'll have to verify all the RRSIGs
to ensure you aren't serving a bogus zone, and this is more expensive than
including the RRSIGs in the hash.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Tyne, Dogger: South or southeast veering southwest 4 or 5, occasionally 6 in
Dogger. Slight or moderate. Showers. Good.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 30 Jul 2018 10:57:46 -0400

> The present and long-standing system provides the recursive resolvers with well-oiled and highly effective solutions to (a) finding the root servers and (b) getting highly reliable and highly respo…

Nod.

> It seems to me reasonable and reasonably easy to sustain these attributes as we evolve toward downloading the entire root zone instead of individual pieces of it.

Vigorus nod.

> And by "evolution" we're necessarily talking about a lengthy period of hybrid operation.

Nod.

> There will likely be a growing set of recursive resolvers downloading the full root zone and but there will certainly be a very large set of recursive resolvers that continue to operate in the current model.

Nod...

> Even if there were to be an aggressive push toward hyper local root service, the existing service would have to remain as is for a long time.  And by "a long time" I'm guessing ten years is not enough, so I suspect it will be twenty years before one can imagine the current root service reaching twilight.

Nod (I would have said much more than 20 years, but ok).

>
> The heated concern of several years ago about the potential size of the root zone is behind us, I hope.  The root zone is not going to grow exponentially.  The whole zone will be in the single megabyte range, I think.  (Caution: I haven't looked at the actual size.  Apologies if I am off a bit.  But the overall point is still right.  Another round or so of gTLDs might double or even triple the current size of the root zone, but it will not grow by even one order of magnitude and certainly not by multiple orders of magnitude.)

Nod.
wkumari$ dig axfr . @b.root-servers.net > root.zone
wkumari$ ls -alh root.zone
-rw-r--r--  1 wkumari  staff   2.1M Jul 30 10:34 root.zone

2.1MB - close enough.

>
> Distribution of a megabyte or even a few megabytes to, say, a million recursive resolvers twice a day is a relatively modest endeavor on today's Internet.

Nod. 2.1MB times 1M resolvers is ~2TB (or the size of a medium
capacity SSD drive)

> If there are going to be problems, I suspect they won't be related to ad hoc fetching of the root zone from random untrusted sources.

Citation needed :-)

Regardless of where I get the root zone (trusted source, untrusted
source) I'd like to be able to make sure if it is accurate and
complete.
For example, I just fetched the root zone via AXFR from
b.root-servers.net in MIA, a server which, for various reasons I trust
implicitly. However, I'm not really sure I trust the network between
it and myself - and if I'm planning on using this zone in a production
environment I'd really like to be able to know that someone hasn't
monkeyed with it between b.root-servers.net and myself.
When I open the zone and it contains:
-----
aaa.                    172800  IN      NS      ns1.dns.nic.aaa.
aaa.                    172800  IN      NS      ns2.dns.nic.aaa.
aaa.                    172800  IN      NS      ns3.dns.nic.aaa.
aaa.                    172800  IN      NS      ns4.dns.nic.aaa.
aaa.                    172800  IN      NS      ns5.dns.nic.aaa.
aaa.                    172800  IN      NS      ns6.dns.nic.aaa.
aaa.                    86400   IN      DS      21707 8 1
6D92DD0D0DB0E392FA9D5F08EA15BBD297B8CBE2
aaa.                    86400   IN      DS      21707 8 2
4F74856F31B73F3BFCDF430985329F55AA655BC9E53C4BF9DC6B14CC E6780600
aaa.                    86400   IN      DS      28192 8 1
563200F63B8B1797B4D88D14BD6A672EA4D0CC0C
aaa.                    86400   IN      DS      28192 8 2
DCB5AA6EC2B73D3E8C82D481770151160B38BCF2DBF3B9CD587AAD38 8D3572D7
aaa.                    86400   IN      RRSIG   DS 8 1 86400
20180812050000 20180730040000 41656 .
9pGWZzPrVVFeqif5/PwqlO4BeFcTn2fvE1u5Mv5ADl5xn5vgm1WnWrnB
5Fxuk8TYIWFKhZ19DPk8RaU5Qk/kJpB/7A596x+XJ4IkaaMhlfAWYGYo
9C3cr5yj34FtLKlhU5tE3mSyt4lfyg558hSpwgo6cQPTj78KmkBkzjty
X/ZeYTcSZX+zcIK2pNB1bG5yU4IEJbqye4LrKUqVKJ48bJI3pa6tci+b
SFkGbqhotRfVdXSuNqZ/njLn+mH/vGIVKlMB5IwLe7Jf7lA1bFlMT4pP
BACKPMletFgDMlTaMocqmbRBhRUDHnf93+vSoqxykwB+GLO7A/J3k2FZ NqKDtg==
aaa.                    86400   IN      NSEC    aarp. NS DS RRSIG NSEC
aaa.                    86400   IN      RRSIG   NSEC 8 1 86400
20180812050000 20180730040000 41656 .
1MIOeZb204La5r+b71rZxl39WqfVFp4z0kDRh2xd881mW1OICp7zUS1Y
qOn/T3WTFQQG+39UVB2uQT+kcwL+rDLN2LGQhTFUzWLTom0oVEzO7rGu
zUzbvqMJ0YBtrVqqzxcGYQ0lzGwUgn2qWyFPe6tUXZX3LmJgTT0yHzYT
pG0cdEFc/7/7dnXgZIn7LSpOWc8m+Pxz7PSqjQ503cD+UqeJhYRpqTFy
YG+UWchXoVZrs0qF6qsqgxdIsGcoeD+0Mh7eondWl4IPNT6UZ1iIxM9q
hTNu5y/qyvEW/M20cRGVtY7B9h7RY7d6ASGAbYybeYljG2TBNqYyD9Bh GDg0ow==
ns1.dns.nic.aaa.        172800  IN      A       127.0.0.1
ns1.dns.nic.aaa.        172800  IN      AAAA    ::1
ns2.dns.nic.aaa.        172800  IN      A       127.0.0.2
ns2.dns.nic.aaa.        172800  IN      AAAA   ::2
ns3.dns.nic.aaa.        172800  IN      A       192.168.1.1
ns3.dns.nic.aaa.        172800  IN      AAAA    ::3
----
I'd really like to know if the 127.0.0.1 was there when the zone was
signed, and that it hasn't been "fixed" by something on path.

W

---

From: "John R Levine" <[email-masked]>
Date: 30 Jul 2018 11:38:33 -0400

> I know some people have 40Gbps at mothers house, but for general usefulness you want to prevent downloading fake (or otherwise invalid) zone before you start downloading it.

This feels like what we call in the US moving the goalposts.

How do you know now that an AXFR isn't going to contain a gigabyte of 
malware, other than hoping that the other end is trustworthy? 
Personally, I download linux files by bittorrent without worrying about 
it, even though I am aware that there are copyright trolls who seed 
"unauthorized" copies of dirty movies and send out mass infringement 
threats.  How you download and how you verify are separate questions.

Regards,

---

From: Evan Hunt <[email-masked]>
Date: Mon, 30 Jul 2018 17:29:52 +0000

On Mon, Jul 30, 2018 at 09:19:14AM +0200, Ondřej Surý wrote:
> I know some people have 40Gbps at mothers house, but for general
> usefulness you want to prevent downloading fake (or otherwise invalid)
> zone before you start downloading it.

While this does seem like a potentially useful feature, I don't think it's
essential to the problem of verifiable root mirroring. "Nice to have",
but not a requirement.

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 30 Jul 2018 21:44:13 +0000

> On Jul 24, 2018, at 7:32 AM, John Levine <[email-masked]> wrote:
> 

I agree with John.

ZONEMD is not about securing any particular transport, AXFR or what-have-you.

While I wouldn't necessarily be opposed to having an RR count field of some kind if there is good reason to have it, my preference would be to omit it and keep the record simpler.

DW

---

From: Mark Andrews <[email-masked]>
Date: Tue, 31 Jul 2018 07:53:09 +1000

You can do what BGP implementations have been doing for decades and
just put a count in that allows for some growth.  Named and I presume
other servers already has the ability to track records during a zone
transfer (AXFR and IXFR) and abort if the count becomes too large. 

The following allows for a ~4x growth.

zone “.” {
	type slave;
	max-records 100000;
	…
};

;; XFR size: 22541 records (messages 22541, bytes 2758345)

That said, I agree with Evan, a in zone count is a “nice to have” feature.

Mark

> On 31 Jul 2018, at 3:29 am, Evan Hunt <[email-masked]> wrote:
>

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 30 Jul 2018 22:09:11 +0000

> On Jul 26, 2018, at 7:39 PM, Steve Crocker <[email-masked]> wrote:
> 

Steve,

I wouldn't put it that way.  I'd say that the servers shouldn't have to trust the sources, they should have the ability to trust the data itself.

>   And why does the source matter if the zone entries are DNSSEC-signed?

Because many records in the (root) zone are not signed.   For example none of this is signed:

org.                    172800  IN      NS      a0.org.afilias-nst.info.
org.                    172800  IN      NS      a2.org.afilias-nst.info.
org.                    172800  IN      NS      b0.org.afilias-nst.org.
org.                    172800  IN      NS      b2.org.afilias-nst.org.
org.                    172800  IN      NS      c0.org.afilias-nst.info.
org.                    172800  IN      NS      d0.org.afilias-nst.org.
b0.org.afilias-nst.org. 172800  IN      A       199.19.54.1
b0.org.afilias-nst.org. 172800  IN      AAAA    2001:500:c::1
b2.org.afilias-nst.org. 172800  IN      A       199.249.120.1
b2.org.afilias-nst.org. 172800  IN      AAAA    2001:500:48::1
d0.org.afilias-nst.org. 172800  IN      A       199.19.57.1
d0.org.afilias-nst.org. 172800  IN      AAAA    2001:500:f::1

If you have an RFC7706 recursive name server you could be given a root zone with changed delegations for any TLD.  

If your recursive name server is validating (which it MUST be per 7706) then probably the worst that would happen is an attack on your privacy.  The bad name servers can proxy DNS queries to the real ones and thus log your query traffic.

If your name server is not validating then, of course, much worse is possible.

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 30 Jul 2018 22:38:55 +0000

> On Jul 29, 2018, at 2:03 PM, Evan Hunt <[email-masked]> wrote:
> 

I may be wrong, but I think Ondrej may have been referencing the idea of using BitTorrent where you request the data by its hash value...

DW

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 30 Jul 2018 15:44:11 -0700

On 30 Jul 2018, at 14:44, Wessels, Duane wrote:

> While I wouldn't necessarily be opposed to having an RR count field of 
> some kind if there is good reason to have it, my preference would be 
> to omit it and keep the record simpler.

I am still mystified about the scenario in which a malicious zone 
operator creates two zone files with the same ZONEMD hash, one with the 
right set of addresses for unsigned child zones, and a different one 
with one of more of those child zones with wrong addresses plus enough 
other kruft to make the colliding hashes match. In what world is that 
attack more likely than just not using ZONEMD?

And, even if it is possible to imagine that, requiring a hash function 
that has no collision attacks (like SHA-256) would suffice.

Adding a RR count field would only make the malicious zone owner's 
attack harder, and would complicate the field. But I still can't picture 
malicious zone operators who would voluntarily use ZONEMD.

--Paul Hoffman

---

From: Evan Hunt <[email-masked]>
Date: Mon, 30 Jul 2018 23:12:36 +0000

> attack more likely than just not using ZONEMD?

I don't think the imagined attack involves a zone operator creating two
zones. It would be a zone operating creating one zone, with a legitimate
and validly signed ZONEMD, and then someone else creating a fake version
of the zone in which all the signed rrsets still validate, and the ZONEMD
still matches, but the unsigned parts have been mucked with. Adding an RR
count does make that attack more expensive. I'm not sure it makes enough
difference to be worthwhile.

Another imagined attack is someone trying to dump terabytes on you when
initiate the zone transfer. An RR count could help with that, if you
looked it up before starting the transfer.

(For the record, I neither favor nor oppose the idea. I don't see much
benefit, but I also don't see much cost.)

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 30 Jul 2018 16:21:15 -0700

On 30 Jul 2018, at 16:12, Evan Hunt wrote:

> still matches, but the unsigned parts have been mucked with.

But that can't happen with any of the hash algorithms allowed by the 
draft. What you are describing is a second preimage attack, and no 
modern hash algorithm (not even MD5!) has any known second preimage 
weaknesses.

The bit that started this thread was a concern about collision attacks. 
Collision attacks can only be mounted by the person who creates the 
hash, by creating two messages that both have the same hash. The 
suggestion was to not allow hash algorithms that had known collision 
resistance reductions (such as MD5 and SHA1), which is fine in general. 
However, as people went on and on about how to make further changes to 
the RRtype, I questioned what collision attack they were thinking of.

> Adding an RR

Exactly.

> looked it up before starting the transfer.

See above. If you are blindly accepting terabytes of data from a trusted 
source, you have other problems.

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 31 Jul 2018 10:47:01 +0200

Yes, thank you.  Seems like the information context was lost in the translation somewhere along the way.

O.
--
Ondřej Surý
[email-masked]

> On 31 Jul 2018, at 00:38, Wessels, Duane <[email-masked]> wrote:
> 
> 
>

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 31 Jul 2018 10:49:41 +0200

> On 31 Jul 2018, at 00:44, Paul Hoffman <[email-masked]> wrote:
> 
> And, even if it is possible to imagine that, requiring a hash function that has no collision attacks (like SHA-256) would suffice.

Yes, that’s exactly what I had suggested in the first place.  Now we have a full circle to my original message.

O.
--
Ondřej Surý
[email-masked]