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

> 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

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

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

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

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,

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

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

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

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

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

> 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

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

> 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

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

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

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

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

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

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,

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

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

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

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 >

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

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,

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

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.

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

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

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

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

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

* 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@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

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

* 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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

> 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

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

> 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

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

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

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

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

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

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

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

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,

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

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

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

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

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

> 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

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

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

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

> 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

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

> 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

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

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

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

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

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

* 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

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

> 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

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

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

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

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

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

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.

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

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

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

> 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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

> 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

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

> 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

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

> 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

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

> 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

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

> 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

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

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

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

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

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

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

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

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

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

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*

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

> 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

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

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

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

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)

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

  1   2   >