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

[Ondřej Surý]

> On 31 Jul 2018, at 00:44, Paul Hoffman  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ý
ond...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

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

O.
--
Ondřej Surý
ond...@isc.org

> On 31 Jul 2018, at 00:38, Wessels, Duane  wrote:
> 
> 
> 
>> On Jul 29, 2018, at 2:03 PM, Evan Hunt  wrote:
>> 
>> On Sun, Jul 29, 2018 at 10:55:31AM +0200, Ondřej Surý wrote:
>>> You need to know the hash is valid before you start the download.
>>> Therefore the hash has to be signed.
>> 
>> Before you *start* the download? Or before you use what you downloaded?
> 
> 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
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

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


On Mon, Jul 30, 2018 at 03:44:11PM -0700, Paul Hoffman wrote:

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?


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.


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
count does make that attack more expensive. I'm not sure it makes 
enough

difference to be worthwhile.


Exactly.

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.


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


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

On Mon, Jul 30, 2018 at 03:44:11PM -0700, Paul Hoffman wrote:
> 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?

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.)

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wessels, Duane]

> On Jul 29, 2018, at 2:03 PM, Evan Hunt  wrote:
> 
> On Sun, Jul 29, 2018 at 10:55:31AM +0200, Ondřej Surý wrote:
>> You need to know the hash is valid before you start the download.
>> Therefore the hash has to be signed.
> 
> Before you *start* the download? Or before you use what you downloaded?

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



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wessels, Duane]

> On Jul 26, 2018, at 7:39 PM, Steve Crocker  wrote:
> 
> The passage below puzzles me.  Why do you want servers to get the root zone 
> from less trusted sources?

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  2001:500:c::1
b2.org.afilias-nst.org. 172800  IN  A   199.249.120.1
b2.org.afilias-nst.org. 172800  IN  2001:500:48::1
d0.org.afilias-nst.org. 172800  IN  A   199.19.57.1
d0.org.afilias-nst.org. 172800  IN  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



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

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 10;
…
};

;; 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  wrote:
> 
> 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.
> 
> -- 
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wessels, Duane]

> On Jul 24, 2018, at 7:32 AM, John Levine  wrote:
> 
> In article <87h8kp7sqf@mid.deneb.enyo.de> you write:
>> 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.
> 
> 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.

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



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

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.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

On Mon, 30 Jul 2018, 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.


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,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Sun, Jul 29, 2018 at 3:09 PM Steve Crocker  wrote:
>
> 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.

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
2018081205 2018073004 41656 .
9pGWZzPrVVFeqif5/PwqlO4BeFcTn2fvE1u5Mv5ADl5xn5vgm1WnWrnB
5Fxuk8TYIWFKhZ19DPk8RaU5Qk/kJpB/7A596x+XJ4IkaaMhlfAWYGYo
9C3cr5yj34FtLKlhU5tE3mSyt4lfyg558hSpwgo6cQPTj78KmkBkzjty
X/ZeYTcSZX+zcIK2pNB1bG5yU4IEJbqye4LrKUqVKJ48bJI3pa6tci+b
SFkGbqhotRfVdXSuNqZ/njLn+mH/vGIVKlMB5IwLe7Jf7lA1bFlMT4pP
BACKPMletFgDMlTaMocqmbRBhRUDHnf93+vSoqxykwB+GLO7A/J3k2FZ NqKDtg==
aaa.86400   IN  NSECaarp. NS DS RRSIG NSEC
aaa.86400   IN  RRSIG   NSEC 8 1 86400
2018081205 2018073004 41656 .
1MIOeZb204La5r+b71rZxl39WqfVFp4z0kDRh2xd881mW1OICp7zUS1Y
qOn/T3WTFQQG+39UVB2uQT+kcwL+rDLN2LGQhTFUzWLTom0oVEzO7rGu
zUzbvqMJ0YBtrVqqzxcGYQ0lzGwUgn2qWyFPe6tUXZX3LmJgTT0yHzYT
pG0cdEFc/7/7dnXgZIn7LSpOWc8m+Pxz7PSqjQ503cD+UqeJhYRpqTFy
YG+UWchXoVZrs0qF6qsqgxdIsGcoeD+0Mh7eondWl4IPNT6UZ1iIxM9q
hTNu5y/qyvEW/M20cRGVtY7B9h7RY7d6ASGAbYybeYljG2TBNqYyD9Bh GDg0ow==

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

[Tony Finch]

John R Levine  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.finchhttp://dotat.at/
Tyne, Dogger: South or southeast veering southwest 4 or 5, occasionally 6 in
Dogger. Slight or moderate. Showers. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

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  wrote:
> 
>> On Sun, Jul 29, 2018 at 10:55:31AM +0200, Ondřej Surý wrote:
>> You need to know the hash is valid before you start the download.
>> Therefore the hash has to be signed.
> 
> Before you *start* the download? Or before you use what you downloaded?
> 
> -- 
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

I realize that hypothetically a malicious server could send you a large
file of garbage. ...



A lot of other updaters use HTTPS, which does not have this issue if
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,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

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  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
> 
> 
>> On Sun, Jul 29, 2018 at 12:44 PM, Joe Abley  wrote:
>> Hi Steve,
>> 
>> On Jul 29, 2018, at 15:09, Steve Crocker  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 

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

[Florian Weimer]

* John R. Levine:

> On Sat, 28 Jul 2018, Florian Weimer wrote:
>> 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.
>
> 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.

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  for specific
take on this subject), and the current ZONEMD draft does not
acknowledge this, even though its goals are broadly similar.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

On Sun, Jul 29, 2018 at 10:55:31AM +0200, Ondřej Surý wrote:
> You need to know the hash is valid before you start the download.
> Therefore the hash has to be signed.

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

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Steve Crocker]

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  wrote:

> Hi Steve,
>
> On Jul 29, 2018, at 15:09, Steve Crocker  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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

Hi Steve,

On Jul 29, 2018, at 15:09, Steve Crocker  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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Steve Crocker]

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  wrote:

> On Jul 29, 2018, at 12:19, Steve Crocker  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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On Jul 29, 2018, at 12:19, Steve Crocker  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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Steve Crocker]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

In article  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.
>
>You need to know the hash is valid before you start the download. Therefore 
>the hash has to be signed.

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?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

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  wrote:

>> 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, ...).
> 
> 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,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

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, ...).


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,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

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  wrote:
> 
> In article <208f049b-b35a-4755-9a20-fa0c7f685...@isc.org> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

In article <208f049b-b35a-4755-9a20-fa0c7f685...@isc.org> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[tjw ietf]

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ý  wrote:
> 
> @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  wrote:
>> 
>> 
>>> On Thu, Jul 26, 2018 at 11:07 PM Mark Andrews  wrote:
>>> 
>>> 
>>> > On 27 Jul 2018, at 12:39 pm, Steve Crocker  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.
>> 
>> 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
>>  
>>> >  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. 
>>> 
>>> > Thanks,
>>> > 
>>> > Steve
>>> > 
>>> > Sent from my iPhone
>>> > 
>>> >> On Jul 26, 2018, at 7:33 PM, Mark Andrews  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.
>>> 
>>> -- 
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

@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  wrote:
> 
> 
>> On Thu, Jul 26, 2018 at 11:07 PM Mark Andrews  wrote:
>> 
>> 
>> > On 27 Jul 2018, at 12:39 pm, Steve Crocker  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.
> 
> 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
>  
>> >  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. 
>> 
>> > Thanks,
>> > 
>> > Steve
>> > 
>> > Sent from my iPhone
>> > 
>> >> On Jul 26, 2018, at 7:33 PM, Mark Andrews  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.
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Florian Weimer]

* Paul Wouters:

> 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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Florian Weimer]

* John R. Levine:

 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. ...
>
>> On the other hand, clients will likely have a pretty good idea for the
>> 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?

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

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. ...



On the other hand, clients will likely have a pretty good idea for the
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, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Florian Weimer]

* John Levine:

> In article <87h8kp7sqf@mid.deneb.enyo.de> you write:
>>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.
>
> 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?

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

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

> > 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.
>
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Fri, Jul 27, 2018 at 3:02 PM 神明達哉  wrote:
>
> At Fri, 27 Jul 2018 10:59:53 +0800,
> Davey Song  wrote:
>
> > > 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.
>
> 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.

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,
> I don't yet think draft-wessels-dns-zone-digest has passed this test.
>
> --
> JINMEI, Tatuya
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

At Fri, 27 Jul 2018 10:59:53 +0800,
Davey Song  wrote:

> > 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

In article  
you write:
>-=-=-=-=-=-
>
>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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

On Thu, Jul 26, 2018 at 11:07 PM Mark Andrews  wrote:

>
>
> > On 27 Jul 2018, at 12:39 pm, Steve Crocker  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.
>

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


> >  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.
>
> > Thanks,
> >
> > Steve
> >
> > Sent from my iPhone
> >
> >> On Jul 26, 2018, at 7:33 PM, Mark Andrews  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.
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Fri, Jul 27, 2018 at 7:28 AM Jim Reid  wrote:

>
> > On 27 Jul 2018, at 12:17, Tony Finch  wrote:
> >
> > Ah, the obvious solution is to deprecate zone files and just ship update
> > journals instead!
>
> Why not go for distributed hash tables? :-)
>
> 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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jim Reid]

> On 27 Jul 2018, at 12:17, Tony Finch  wrote:
> 
> Ah, the obvious solution is to deprecate zone files and just ship update
> journals instead!

Why not go for distributed hash tables? :-)

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Paul Vixie  wrote:
>
> 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.finchhttp://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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

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  wrote:
> 
> 
> 
> On Fri, 27 Jul 2018 at 12:04, Evan Hunt  wrote:
> 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.
> 
>  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
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Davey Song]

On Fri, 27 Jul 2018 at 12:04, Evan Hunt  wrote:

> 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.
>

 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

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
> modifation ( and drop the zone?).

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 -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Thu, Jul 26, 2018 at 11:24 PM Davey Song  wrote:

> 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?).
>

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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Thu, Jul 26, 2018 at 8:38 PM Paul Hoffman  wrote:

> On 26 Jul 2018, at 10:25, Ondřej Surý 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.
> >
> >> What is the attack you are envisioning?
>
> 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.
>

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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Davey Song]

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  wrote:

> On Thu, Jul 26, 2018 at 10:53 PM Steve Crocker  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
>> finding the address of one more trusted sources.  And the existing set of
>> root servers seems like a perfectly good set of trusted sources.
>>
>
> 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.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 27 Jul 2018, at 12:39 pm, Steve Crocker  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. 

> Thanks,
> 
> Steve
> 
> Sent from my iPhone
> 
>> On Jul 26, 2018, at 7:33 PM, Mark Andrews  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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Davey Song]

>
> 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Thu, Jul 26, 2018 at 10:53 PM Steve Crocker  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
> finding the address of one more trusted sources.  And the existing set of
> root servers seems like a perfectly good set of trusted sources.
>

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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Steve Crocker]

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

On Thu, Jul 26, 2018 at 7:45 PM Shumon Huque  wrote:

> On Thu, Jul 26, 2018 at 10:16 PM Davey Song  wrote:
>
>>
>> - 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?
>>
>
> 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.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Steve Crocker]

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  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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 27 Jul 2018, at 12:26 pm, Mark Andrews  wrote:
> 
> 
> 
>> On 27 Jul 2018, at 12:15 pm, Davey Song  wrote:
>> 
>> 
>> - 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? 
> 
> 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.

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.

>> 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
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 27 Jul 2018, at 12:15 pm, Davey Song  wrote:
> 
> 
> - 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? 

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
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Davey Song]

> - 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 27 Jul 2018, at 10:37 am, Paul Hoffman  wrote:
> 
> On 26 Jul 2018, at 10:25, Ondřej Surý 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.
>> 
>>> What is the attack you are envisioning?
> 
> 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.
 
> --Paul Hoffman
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On 26 Jul 2018, at 10:25, Ondřej Surý 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.



What is the attack you are envisioning?


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

--
Ondřej Surý
ond...@isc.org

> On 26 Jul 2018, at 18:48, Paul Hoffman  wrote:
> 
> On 26 Jul 2018, at 9:43, Ondřej Surý wrote:
> 
>>> On 26 Jul 2018, at 18:40, Wessels, Duane  wrote:
>>> 
>>> 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?
>> 
>> That’s probably question you need to ask some cryptographer, so take my 
>> opinion with a grain of salt.
>> 
>> If  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.

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.

> What is the attack you are envisioning?

Ondrej
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

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

On 26 Jul 2018, at 18:40, Wessels, Duane  
wrote:


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?


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


If  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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

> On 26 Jul 2018, at 18:40, Wessels, Duane  wrote:
> 
> 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?

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

If  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ý
ond...@isc.org


> DW
> 
> 
>> On Jul 25, 2018, at 8:47 PM, Ondřej Surý  wrote:
>> 
>> 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ý
>> ond...@isc.org
>> 
>>> On 23 May 2018, at 17:32, Weinberg, Matt 
>>>  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
>>> 
>>> 
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wessels, Duane]

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ý  wrote:
> 
> 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ý
> ond...@isc.org
> 
>> On 23 May 2018, at 17:32, Weinberg, Matt 
>>  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
>> 
>> 
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wessels, Duane]

> On Jul 25, 2018, at 9:24 PM, Paul Wouters  wrote:
> 
> 
>> On Jul 25, 2018, at 20:47, Ondřej Surý  wrote:
>> 
>> 
>> 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.
> 
> That’s why I suggested already to add the count of the number or unsigned 
> records to the ZONEMD record.

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



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

> On Jul 25, 2018, at 20:47, Ondřej Surý  wrote:
> 
> 
> 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.

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

Paul
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

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ý
ond...@isc.org

> On 23 May 2018, at 17:32, Weinberg, Matt 
>  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
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

In article <87h8kp7sqf@mid.deneb.enyo.de> you write:
>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.

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





___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Florian Weimer]

* Duane Wessels:

> 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.

> But it seems to me like this is better suited to be a feature of AXFR
> 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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wessels, Duane]

> On Jul 23, 2018, at 1:47 PM, Paul Hoffman  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

 

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wessels, Duane]

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  wrote:
> 
> 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.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Florian Weimer]

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jaap Akkerhuis]

 Warren Kumari writes:

 >
 > 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Roy Arends]

> On 12 Jul 2018, at 18:55, Warren Kumari  wrote:
> 
> On Thu, Jun 21, 2018 at 4:31 PM 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.
> 
> 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.

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

> 
> 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
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> -- 
> 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
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Thu, Jun 21, 2018 at 4:31 PM 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.

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
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[George Michaelson]

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

On Tue, Jul 10, 2018 at 12:01 PM, Mark Andrews  wrote:
>
>
>> On 10 Jul 2018, at 10:22 am, George Michaelson  wrote:
>>
>> 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
>
> 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
>
>
>
>> On Tue, Jul 10, 2018 at 10:05 AM, Wessels, Duane  
>> wrote:
>>> George,
>>>
>>>
 On Jul 9, 2018, at 4:36 PM, George Michaelson  wrote:

 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.
>>>
>>> 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.
>>>
>>>
>>>
 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?
>>>
>>> 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
 prefer its *not signed* for this mode of transfer, you've stepped
>>>
>>> For me the mode of transfer is irrelevant.  My goal is to secure the data,
>>> not the transfer.
>>>
 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.
>>>
>>> We're not demanding anything (MAY/SHOULD vs MUST) but what we propose is, as
>>> you say, MAC signed by the issuer.
>>>
>>> DW
>>>
>>>

 -G

 On Tue, Jul 10, 2018 at 7:47 AM, Wessels, Duane  
 wrote:
>
>> On Jul 8, 2018, at 6:02 PM, George Michaelson  wrote:
>>
>> So how about use of a PGP key which is a payload in TXT signed over by
>> the 

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

[Mark Andrews]

> On 10 Jul 2018, at 10:22 am, George Michaelson  wrote:
> 
> 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

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



> On Tue, Jul 10, 2018 at 10:05 AM, Wessels, Duane  
> wrote:
>> George,
>> 
>> 
>>> On Jul 9, 2018, at 4:36 PM, George Michaelson  wrote:
>>> 
>>> 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.
>> 
>> 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.
>> 
>> 
>> 
>>> 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?
>> 
>> 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
>>> prefer its *not signed* for this mode of transfer, you've stepped
>> 
>> For me the mode of transfer is irrelevant.  My goal is to secure the data,
>> not the transfer.
>> 
>>> 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.
>> 
>> We're not demanding anything (MAY/SHOULD vs MUST) but what we propose is, as
>> you say, MAC signed by the issuer.
>> 
>> DW
>> 
>> 
>>> 
>>> -G
>>> 
>>> On Tue, Jul 10, 2018 at 7:47 AM, Wessels, Duane  
>>> wrote:
 
> On Jul 8, 2018, at 6:02 PM, George Michaelson  wrote:
> 
> 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..
 
 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
 
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

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

[George Michaelson]

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

On Tue, Jul 10, 2018 at 10:05 AM, Wessels, Duane  wrote:
> George,
>
>
>> On Jul 9, 2018, at 4:36 PM, George Michaelson  wrote:
>>
>> 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.
>
> 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.
>
>
>
>> 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?
>
> 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
>> prefer its *not signed* for this mode of transfer, you've stepped
>
> For me the mode of transfer is irrelevant.  My goal is to secure the data,
> not the transfer.
>
>> 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.
>
> We're not demanding anything (MAY/SHOULD vs MUST) but what we propose is, as
> you say, MAC signed by the issuer.
>
> DW
>
>
>>
>> -G
>>
>> On Tue, Jul 10, 2018 at 7:47 AM, Wessels, Duane  
>> wrote:
>>>
 On Jul 8, 2018, at 6:02 PM, George Michaelson  wrote:

 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..
>>>
>>> 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
>>>
>

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wessels, Duane]

George,


> On Jul 9, 2018, at 4:36 PM, George Michaelson  wrote:
> 
> 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.

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.



> 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?

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
> prefer its *not signed* for this mode of transfer, you've stepped

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

> 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.

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

DW


> 
> -G
> 
> On Tue, Jul 10, 2018 at 7:47 AM, Wessels, Duane  wrote:
>> 
>>> On Jul 8, 2018, at 6:02 PM, George Michaelson  wrote:
>>> 
>>> 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..
>> 
>> 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
>> 



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[George Michaelson]

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

On Tue, Jul 10, 2018 at 7:47 AM, Wessels, Duane  wrote:
>
>> On Jul 8, 2018, at 6:02 PM, George Michaelson  wrote:
>>
>> 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..
>
> 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
>

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wessels, Duane]

> On Jul 8, 2018, at 8:39 PM, Olafur Gudmundsson  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 ? 

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

DW




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wessels, Duane]

> On Jul 8, 2018, at 6:02 PM, George Michaelson  wrote:
> 
> 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..

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



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Wessels, Duane]

> On Jul 8, 2018, at 5:28 PM, Olafur Gudmundsson  wrote:
> 
> 
> +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. 

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





smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

> On Jul 8, 2018, at 9:35 PM, Mark Andrews  wrote:
> 
> 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

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

>> On 9 Jul 2018, at 10:28 am, Olafur Gudmundsson  wrote:
>> 
>> 
>> 
>>> On Jun 22, 2018, at 6:58 AM, Petr Špaček  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
>>> DNSOP@ietf.org
>>> 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
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 9 Jul 2018, at 11:27 am, Joe Abley  wrote:
> 
> On Jul 9, 2018, at 02:02, George Michaelson  wrote:
> 
>> wow. Firstly, I thought canonicalization was a given: we have
>> definitions of canonical zone order for other reasons (NSEC*) don't
>> we?
> 
> 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.

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

> Joe
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

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  wrote:
> 
> 
> 
>> On Jun 22, 2018, at 6:58 AM, Petr Špaček  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
>> DNSOP@ietf.org
>> 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
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[George Michaelson]

On Mon, Jul 9, 2018 at 11:23 AM, Olafur Gudmundsson  wrote:

> 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On Jul 9, 2018, at 02:02, George Michaelson  wrote:

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

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  wrote:
> 
> 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  wrote:
>> 
>> 
>> On Jun 22, 2018, at 6:58 AM, Petr Špaček  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
>> DNSOP@ietf.org
>> 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
>> 

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

[George Michaelson]

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  wrote:
>
>
> On Jun 22, 2018, at 6:58 AM, Petr Špaček  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
> DNSOP@ietf.org
> 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
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

> On Jun 22, 2018, at 6:58 AM, Petr Špaček  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
> DNSOP@ietf.org 
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Wed, Jun 20, 2018 at 9:15 PM Shumon Huque  wrote:

> On Tue, Jun 19, 2018 at 7:15 PM Mukund Sivaraman  wrote:
>
>>
>> There also seems to be a scalability problem with SIG(0) in that
>> generating the signature involves a public-key operation per DNS
>> message.
>>
>> For a zone transfer of the root zone from F, the AXFR contains 79
>> messages in the TCP continuation:
>>
>> ;; XFR size: 22554 records (messages 79, bytes 1335768)
>>
>
> Yup, I realize that. That was one fo the reasons is I mentioned that
> SIG(0) can
> also sign IXFR messages if they are available from the server, which could
> significantly reduce the performance impact. Thinking about it more now
> though,
> I recall that the current root zone management scheme isn't that conducive
> to
> incremental transfer, since the zone is signed monolithically twice a day
> (IIRC).
>

One other comment on this: Getting better performance than this requires
re-inventing
something akin to TLS key exchange, and I was wondering if anyone had
thought of that
during the development of SIG(0). And sure enough, RFC 2930 proposes (among
other
things) SIG(0) authenticated symmetric key establishment using TKEY, either
via
Diffie-Hellman or client chosen key transport.

So, together with AXFR-SIG (i.e. full zone signature), Don Eastlake appears
to have
long ago contemplated most of the design space around this draft and its
problem space!
:-)

Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Petr Špaček]

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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Petr Špaček]

On 21.6.2018 18:46, Shumon Huque wrote:
> On Thu, Jun 21, 2018 at 2:19 AM Petr Špaček  > wrote:
> 
> 
> HTTPS over TLS is what we did for root zone import into Knot Resolver's
> cache (from version 2.3 onwards but beware, there are little bugs which
> were fixed in 2.4 - to be released soon).
> 
> 
> Out of curiosity, which HTTPS source are you using for the root zone import?

It is user configurable and examples in docs
http://knot-resolver.readthedocs.io/en/latest/modules.html#cache-prefilling
use
https://www.internic.net/domain/root.zone

After download the data are DNSSEC validated and inserted into cache.

-- 
Petr Špaček  @  CZ.NIC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 22 Jun 2018, at 1:55 am, Wessels, Duane 
>  wrote:
> 
> 
>> On Jun 20, 2018, at 11:19 PM, Petr Špaček  wrote:
>> 
>>> 
>>> Longer term, perhaps the best solution will end up being XFR using DNS over 
>>> TLS (or HTTPS) with server authentication. Yes, I realize that authoritative
>>> servers are not yet the targets of those protocols, but it's probably
>>> only a matter
>>> of time.
>> 
>> HTTPS over TLS is what we did for root zone import into Knot Resolver's
>> cache (from version 2.3 onwards but beware, there are little bugs which
>> were fixed in 2.4 - to be released soon).
> 
> The problem I'm seeking to solve is somewhat different, and its probably
> not clearly stated in the draft so I will add some text to rectify that.
> 
> I'm not trying to solve the problem that SIG(0), SIG(AXFR), or TLS addresses
> -- that you're talking to the right server and that data wasn't modified
> in transit.
> 
> My goal is to ensure that when you receive a zone file -- however you
> receive it (DNS, HTTPS, P2P file sharing, Avian Carrier) -- you get the
> data that the zone publisher actually published.

SIG(AXFR) does that.  It is part of the zone’s contents.

> DW
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Hugo Salgado-Hernández]

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.

Hugo



signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shane Kerr]

Petr,

Petr Špaček:

Dne 1.6.2018 v 12:51 Shane Kerr napsal(a):

Wessels, Duane:



On May 25, 2018, at 11:33 AM, 神明達哉  wrote:

At Wed, 23 May 2018 15:32:11 +,
"Weinberg, Matt"  wrote:


We’ve posted a new version of draft-wessels-dns-zone-digest.  Of note,

this -01 version includes the following changes:
[...]

We plan to ask for time on the dnsop agenda in Montreal.  Your
feedback

is welcome and appreciated.

I've read the draft.  I have a few high level comments and specific
feedback on the draft content:

- 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.


Thanks you for the feedback.  We will write a clearer problem statement
in the introduction for the next version.


As I mentioned, I have seen zones broken during transfer in production,
and having a standard way to check for this seems reasonable.


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.


Another scenario is when you are not using TSIG at all. For my own zones
I don't bother because I don't have any confidential data in them and I
prefer the operational simplicity of not having to set up keys 
everywhere. But this may also be the case for things like the root zone 
where the zone publishers explicitly want people to be able to transfer 
the zones without authentication.



I wonder if this proposal is worth the complexity ... If we wanted plain
checksum we could use TSIG with built-in key (all zeroes or so) and to
get checksum for the network part with negligible implementation
complexity. (TSIG trick is Mukund's idea, not mine


I kind of like this approach. It doesn't provide any help for 
stand-alone zone files, but in general there is no interoperability 
requirement there and a simple sha256sum file is probably good enough.


Instead of zone digest maybe it makes sense to document Mukund's 
approach in an informational (?) RFC? It still doesn't solve problems 
where something on the receiving side doesn't work due to an 
implementation bug, but I'm basically okay with the recommendation being 
"don't run software that doesn't work". 


Cheers,

--
Shane

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On 21 Jun 2018, at 9:40, Shumon Huque wrote:


My goal is to ensure that when you receive a zone file -- however you
receive it (DNS, HTTPS, P2P file sharing, Avian Carrier) -- you get 
the

data that the zone publisher actually published.



I can't argue with that goal (and yes, you should probably clarify it 
in

the draft).


Fully agree. However, Duane's goal is only reachable if the zone is 
DNSSEC signed. Otherwise, an attacker can just change zone contents and 
the hash as well.



The question for me is what are the use cases for this protocol
enhancement, and is this the only way to satisfy those use cases?


Yes, the use cases are pretty central here. As we have discovered in the 
DOH WG, DNS folks can read a document and come away with quite different 
use cases from the authors *and* from each other, all the time thinking 
that their use case is obvious.


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.


While "many" consumers think that is OK, some (very vocally) do not. 
Having a hash over the complete root zone, and having that recorded as 
part of the signed zone, should satisfy those that do not want a second 
trust anchor (that is, for the channel security).


The normal case of distributing a zone securely to all your 
authoritative

server operators, I believe, is adequately satisfied today by zone
transfers authenticated by pre-configured static TSIG keys provisioned
between the authorized parties. Do you see the full zone signature as 
a
replacement for this scenario too? (There are many zones much larger 
and

more frequently updated than the root zone, for which I believe the
computational cost of this is too prohibitive).

As noted earlier, out of band verification of the full zone using an
integrated signature that does not rely on an external keying
infrastructure, is also a plausible use case. I'm just wondering if it 
has

a compelling need.

Anyway, not trying to derail this effort, just asking questions. On
balance, I think I support this draft.


I agree, as long as the use cases are made clear so that we can compare 
the solution against them.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Thu, Jun 21, 2018 at 2:19 AM Petr Špaček  wrote:

>
> HTTPS over TLS is what we did for root zone import into Knot Resolver's
> cache (from version 2.3 onwards but beware, there are little bugs which
> were fixed in 2.4 - to be released soon).
>

Out of curiosity, which HTTPS source are you using for the root zone import?

Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Thu, Jun 21, 2018 at 11:56 AM Wessels, Duane  wrote:

>
> The problem I'm seeking to solve is somewhat different, and its probably
> not clearly stated in the draft so I will add some text to rectify that.
>
> I'm not trying to solve the problem that SIG(0), SIG(AXFR), or TLS
> addresses
> -- that you're talking to the right server and that data wasn't modified
> in transit.
>
> My goal is to ensure that when you receive a zone file -- however you
> receive it (DNS, HTTPS, P2P file sharing, Avian Carrier) -- you get the
> data that the zone publisher actually published.
>

I can't argue with that goal (and yes, you should probably clarify it in
the draft).

The question for me is what are the use cases for this protocol
enhancement, and is this the only way to satisfy those use cases?

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.

The normal case of distributing a zone securely to all your authoritative
server operators, I believe, is adequately satisfied today by zone
transfers authenticated by pre-configured static TSIG keys provisioned
between the authorized parties. Do you see the full zone signature as a
replacement for this scenario too? (There are many zones much larger and
more frequently updated than the root zone, for which I believe the
computational cost of this is too prohibitive).

As noted earlier, out of band verification of the full zone using an
integrated signature that does not rely on an external keying
infrastructure, is also a plausible use case. I'm just wondering if it has
a compelling need.

Anyway, not trying to derail this effort, just asking questions. On
balance, I think I support this draft.

Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop