Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
> On 3 Aug 2018, at 1:36 pm, Paul Wouters wrote: > > On Thu, 2 Aug 2018, Paul Hoffman wrote: > >> That only works for validating resolvers. ZONEMD also is useful for >> non-validating resolvers. > >> A non-validating resolver doesn't have a validated cache. > > The internet is no place for spoofable data in any kind of protocol. > > I don't think the IETF should provide DNS-without-DNSSEC solutions, > just like we don't do SHA1 or MD5 or IKEv1 or TLS 1.0 anymore. > > We should not make things more complicated to allow for dnssecless. > > A non-validating resolver is on its own. Nothing can save it. > > Paul +1. We don’t need to split out the hash from the signature. -- 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] One Chair's comments on draft-wessels-dns-zone-digest
On Thu, 2 Aug 2018, Paul Hoffman wrote: That only works for validating resolvers. ZONEMD also is useful for non-validating resolvers. A non-validating resolver doesn't have a validated cache. The internet is no place for spoofable data in any kind of protocol. I don't think the IETF should provide DNS-without-DNSSEC solutions, just like we don't do SHA1 or MD5 or IKEv1 or TLS 1.0 anymore. We should not make things more complicated to allow for dnssecless. A non-validating resolver is on its own. Nothing can save it. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
On 2 Aug 2018, at 19:50, Paul Wouters wrote: On Thu, 2 Aug 2018, Paul Hoffman wrote: Note that the checksum in this case must be at least as cryptographically strong as the signature algorithm used in the individual RRSIGs/DNSKEYs. Not true. If the resolver is validating, the ZONEMD only adds assurance that the non-signed records are there. Thus, the hash algorithm for the zone is unrelated to the hash algorithms in the signatures. Then don't cover signed RRsets with ZONEMD. Then this problem goes away, and you force implementations to validate all records before putting them in the cache. That only works for validating resolvers. ZONEMD also is useful for non-validating resolvers. If the resolver is not validating, the ZONEMD assures that all the records are there. The strength of that assurance is the same as the second pre-image strength of the hash. However, the resolver cannot say "oh, look, now I can start resolving with what I got in the zone transfer": it still needs to validate every RRSIG all the way to the root. That's not what people are going to do. They are going to grab the AXFR'ed data, check the checksum and throw it in the "validated" cache and they won't revalidate every root zone entry they are about to serve. A non-validating resolver doesn't have a validated cache. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
>> If the resolver is not validating, the ZONEMD assures that all the records >> are there. The strength of that assurance is the same as the second >> pre-image >> strength of the hash. However, the resolver cannot say "oh, look, now I can >> start resolving with what I got in the zone transfer": it still needs to >> validate every RRSIG all the way to the root. > >That's not what people are going to do. They are going to grab the >AXFR'ed data, check the checksum and throw it in the "validated" cache >and they won't revalidate every root zone entry they are about to serve. Why would my copy of nsd handle it differently than the copy of the root it AXFRs now? Also, still wondering about that second preimage downgrade attack. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
> On 3 Aug 2018, at 10:35 am, Paul Hoffman wrote: > > On 2 Aug 2018, at 12:14, Paul Wouters wrote: > >> On Tue, 31 Jul 2018, Matt Larson wrote: >> >>> For all those reasons, I think a checksum in the zone file itself that can >>> be verified with DNSSEC is the best option for this use case, and I like >>> the ZONEMD solution. >> >> Note that the checksum in this case must be at least as >> cryptographically strong as the signature algorithm used >> in the individual RRSIGs/DNSKEYs. > > Not true. > > If the resolver is validating, the ZONEMD only adds assurance that the > non-signed records are there. Thus, the hash algorithm for the zone is > unrelated to the hash algorithms in the signatures. ZONEMD also adds assurances that RRSIGs have not been removed. ZONEMD also adds assurances that RRSIGs for unsupported algorithms have not been tampered with except for RRSIG(ZONEMD). SIG(AXFR) was designed to validate the entire zone (no need to validate individual RRsets). RRSIG(ZONEMD) should be able to validate the entire zone. > If the resolver is not validating, the ZONEMD assures that all the records > are there. The strength of that assurance is the same as the second pre-image > strength of the hash. However, the resolver cannot say "oh, look, now I can > start resolving with what I got in the zone transfer": it still needs to > validate every RRSIG all the way to the root. > >> This would have to be >> enforced by software/RFC to prevent a downgrade attack. > > Given the above, what downgrade attack are you thinking of? > > --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] One Chair's comments on draft-wessels-dns-zone-digest
On Thu, 2 Aug 2018, Paul Hoffman wrote: Note that the checksum in this case must be at least as cryptographically strong as the signature algorithm used in the individual RRSIGs/DNSKEYs. Not true. If the resolver is validating, the ZONEMD only adds assurance that the non-signed records are there. Thus, the hash algorithm for the zone is unrelated to the hash algorithms in the signatures. Then don't cover signed RRsets with ZONEMD. Then this problem goes away, and you force implementations to validate all records before putting them in the cache. If the resolver is not validating, the ZONEMD assures that all the records are there. The strength of that assurance is the same as the second pre-image strength of the hash. However, the resolver cannot say "oh, look, now I can start resolving with what I got in the zone transfer": it still needs to validate every RRSIG all the way to the root. That's not what people are going to do. They are going to grab the AXFR'ed data, check the checksum and throw it in the "validated" cache and they won't revalidate every root zone entry they are about to serve. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
On 2 Aug 2018, at 12:14, Paul Wouters wrote: On Tue, 31 Jul 2018, Matt Larson wrote: For all those reasons, I think a checksum in the zone file itself that can be verified with DNSSEC is the best option for this use case, and I like the ZONEMD solution. Note that the checksum in this case must be at least as cryptographically strong as the signature algorithm used in the individual RRSIGs/DNSKEYs. Not true. If the resolver is validating, the ZONEMD only adds assurance that the non-signed records are there. Thus, the hash algorithm for the zone is unrelated to the hash algorithms in the signatures. If the resolver is not validating, the ZONEMD assures that all the records are there. The strength of that assurance is the same as the second pre-image strength of the hash. However, the resolver cannot say "oh, look, now I can start resolving with what I got in the zone transfer": it still needs to validate every RRSIG all the way to the root. This would have to be enforced by software/RFC to prevent a downgrade attack. Given the above, what downgrade attack are you thinking of? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
In article you write: >On Tue, 31 Jul 2018, Matt Larson wrote: > >> For all those reasons, I think a checksum in the zone file itself that can >> be verified with DNSSEC is the best option for this use case, and I like the >ZONEMD solution. > >Note that the checksum in this case must be at least as >cryptographically strong as the signature algorithm used >in the individual RRSIGs/DNSKEYs. This would have to be >enforced by software/RFC to prevent a downgrade attack. As someone else pointed out, this would be a second-preimage attack. As far as I know, even the cruddy old hashes like MD5 and SHA-1 aren't subject to it. Could you explain in more detail what sort of downgrade attack you're thinking of? R's, John PS: I have no objection to making a list of hash functions for ZONEMD that currently only includes SHA-256. I mean, why not? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
On Tue, 31 Jul 2018, Matt Larson wrote: For all those reasons, I think a checksum in the zone file itself that can be verified with DNSSEC is the best option for this use case, and I like the ZONEMD solution. Note that the checksum in this case must be at least as cryptographically strong as the signature algorithm used in the individual RRSIGs/DNSKEYs. This would have to be enforced by software/RFC to prevent a downgrade attack. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
In your letter dated Tue, 31 Jul 2018 06:49:04 -0700 you wrote: >> I think there is a big difference between distributing the root zone and >> distributing a few 'local' zones. >> >> In the first case you need something that is massively scalable. > >I'm afraid I don't see those as different problems like you do. I'd >like a massively scalable way of distributing any zone, not just the >root. If for no other reason, .arpa and root-servers.net should be >included too, for example. > >Yes, huge zones like .com and similar are not possible. But there are >many other TLDs that likely are possible to pre-cache and serve locally. I'm curious how that is going to be provisioned at a large scale. We don't really know how to roll the KSK of the root zone. I wonder how we are going to manage thousands, maybe millions, and if you are unlucky billions of devices that want to fetch some zone files. Would we paint ourselves into a corner with repect to TTLs? Currently, if the root would need to have lower TTLs then that would require coordination with the root server operators, but that's it. If many devices are hardwired to fetch the root at a fixed rate, you can't do that. If you make the rate a parameter then the first time you try to lower it, you find that some large subset accidentally wired the parameter. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
> Are you suggesting that web servers can't be massively scaleable > ? > I'm not sure I understand your examples. Yes, you can build massively scaleable web servers, but at what price? What if some popular IoT device starts to fetch the root zone. And at a high rate? > You cite overprovisionoing in the root server system as a reason > not to try and supplement it, but I think it makes sense to look > at it the other way round -- if there were ways to distribute th > e > root zone reliably and accurately without presenting the attack > targets that the root server system does, the need for continued > investment in the infrastructure could be reduced (or the effect > ive > benefit to end-users from that investment could be increased). What if your web servers are not massively overprovisioned? Can we handle failures there. If you do massively overprovision those web servers, will it actually be cheaper or better than the current system? > The bandwidth available at the consumer edge, where a lot of the > attack sources now live, continues to grow far faster than the > bandwidth that can be provisioned at the root server edge. The > observation that "there's enough bandwidth that we're safe" does > n't > seem future-proof (it doesn't even seem present-proof, really). >From a ddos point of view there doesn't seem to be big difference between how the current DNS root absorbs traffic and what a highly available web service would have to do. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
> On Jul 31, 2018, at 5:44 AM, Philip Homburg > wrote: > > I wonder if there still is a use case for distributing the root zone. With > QNAME minimization and NXDOMAIN based on NSEC records, the major use cases > seem to be gone. Compared to other zones, the root is massively over > provisioned. So if (from an availability point of view) there is need to have > a local copy of the root, then you would need a local copy of .com as well. A local copy of the root zone improves availability in and of itself because of its importance as the starting point of all resolution. While the root zone is indeed massively over provisioned, the bad guys will always be able to send more traffic: that's an un-winnable arms race. And over provisioning doesn't help me if reachability is poor from my particular vantage point. Availability will therefore always be a concern. Sure, a local copy of .com would (further) improve availability, but that's entirely impractical given the zone's size and rate of change. We're fortunate that the critically important root zone is small enough and changes infrequently enough that having a local copy is a realistic option. I don't think we should assume only (or even primarily) AXFR for root zone distribution on a massive scale. Building a scalable infrastructure for that is a significant expense that I don't think is necessary (for the root operators or anyone else) when distributing 2MB files is a problem that's been solved other ways many times over. Why not distribute the root zone via, for example, multiple CDNs? To verify the integrity of the downloaded zone one could validate all the RRSIGs, but that opens up the DOS and privacy attacks that have been described elsewhere in this discussion. And even if we issue admonitions to not have a local copy of the root zone without also enabling DNSSEC validation, we know that realistically there will be those who do the former without the latter. For all those reasons, I think a checksum in the zone file itself that can be verified with DNSSEC is the best option for this use case, and I like the ZONEMD solution. Matt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
Philip Homburg writes: > I think there is a big difference between distributing the root zone and > distributing a few 'local' zones. > > In the first case you need something that is massively scalable. I'm afraid I don't see those as different problems like you do. I'd like a massively scalable way of distributing any zone, not just the root. If for no other reason, .arpa and root-servers.net should be included too, for example. Yes, huge zones like .com and similar are not possible. But there are many other TLDs that likely are possible to pre-cache and serve locally. > In the second case, just create a tar file with a zone file and a hash, put > it up on a web server and the problem is solved. Verifying the contents of a > file is not exactly a new problem. No, very true. But a standardized and agreed upon way of doing it for DNS zone data currently doesn't exist. That's what we're trying to accomplish. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
Hi Philip, Are you suggesting that web servers can't be massively scaleable? I'm not sure I understand your examples. You cite overprovisionoing in the root server system as a reason not to try and supplement it, but I think it makes sense to look at it the other way round -- if there were ways to distribute the root zone reliably and accurately without presenting the attack targets that the root server system does, the need for continued investment in the infrastructure could be reduced (or the effective benefit to end-users from that investment could be increased). The bandwidth available at the consumer edge, where a lot of the attack sources now live, continues to grow far faster than the bandwidth that can be provisioned at the root server edge. The observation that "there's enough bandwidth that we're safe" doesn't seem future-proof (it doesn't even seem present-proof, really). For "root server system" also read "publishing system for any zone that people care about" -- the root server system is just a handy example. Joe On Jul 31, 2018, at 05:44, Philip Homburg wrote: >>> The draft states in the Motivation section: >>> >>>"The motivation and design of this protocol enhancement is tied to the >> DNS root zone [InterNIC]." >> >> That may be a motivation, but as a prospective user I want to use >> it for much more. My LocalRoot server is already going to be >> serving 3 zones, and I have plans for many more. It would be >> helpful to know that on the distribution side of things that I had >> indeed grabbed an authentic source before sending it off to all >> the resolvers that want to pre-cache a random zone X. >> >> Be careful that we don't collectively interpret the sentence you >> quote as meaning 'this is only useful for the root zone' just >> because that was the original motivation. > > I think there is a big difference between distributing the root zone and > distributing a few 'local' zones. > > In the first case you need something that is massively scalable. > > In the second case, just create a tar file with a zone file and a hash, put > it up on a web server and the problem is solved. Verifying the contents of a > file is not exactly a new problem. > > I wonder if there still is a use case for distributing the root zone. With > QNAME minimization and NXDOMAIN based on NSEC records, the major use cases > seem to be gone. Compared to other zones, the root is massively over > provisioned. So if (from an availability point of view) there is need to have > a local copy of the root, then you would need a local copy of .com as well. > > Though I'm sure that are people who want to reinvent DNSSEC. > > One final remark, maybe it is worth investigating a 'NSDEL' record type, > and possibly 'ADEL' and 'DEL'. Which are the equivalents of NS, A, > for delegations/glue. With separate record types, we can define that they are > covered by a RRSIG. Solving issues with data not being signed. > > ___ > 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] One Chair's comments on draft-wessels-dns-zone-digest
> > The draft states in the Motivation section: > > > > "The motivation and design of this protocol enhancement is tied to the > DNS root zone [InterNIC]." > > That may be a motivation, but as a prospective user I want to use > it for much more. My LocalRoot server is already going to be > serving 3 zones, and I have plans for many more. It would be > helpful to know that on the distribution side of things that I had > indeed grabbed an authentic source before sending it off to all > the resolvers that want to pre-cache a random zone X. > > Be careful that we don't collectively interpret the sentence you > quote as meaning 'this is only useful for the root zone' just > because that was the original motivation. I think there is a big difference between distributing the root zone and distributing a few 'local' zones. In the first case you need something that is massively scalable. In the second case, just create a tar file with a zone file and a hash, put it up on a web server and the problem is solved. Verifying the contents of a file is not exactly a new problem. I wonder if there still is a use case for distributing the root zone. With QNAME minimization and NXDOMAIN based on NSEC records, the major use cases seem to be gone. Compared to other zones, the root is massively over provisioned. So if (from an availability point of view) there is need to have a local copy of the root, then you would need a local copy of .com as well. Though I'm sure that are people who want to reinvent DNSSEC. One final remark, maybe it is worth investigating a 'NSDEL' record type, and possibly 'ADEL' and 'DEL'. Which are the equivalents of NS, A, for delegations/glue. With separate record types, we can define that they are covered by a RRSIG. Solving issues with data not being signed. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
Tim Wicinski writes: > The draft states in the Motivation section: > > "The motivation and design of this protocol enhancement is tied to the > DNS root zone [InterNIC]." That may be a motivation, but as a prospective user I want to use it for much more. My LocalRoot server is already going to be serving 3 zones, and I have plans for many more. It would be helpful to know that on the distribution side of things that I had indeed grabbed an authentic source before sending it off to all the resolvers that want to pre-cache a random zone X. Be careful that we don't collectively interpret the sentence you quote as meaning 'this is only useful for the root zone' just because that was the original motivation. In fact, I'd even argue to remove that sentence if it's causing such confusion. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
> On Jul 28, 2018, at 2:30 AM, Tim Wicinski wrote: > > (these are just my comments alone. So take it as such) Thanks Tim, I don't think these questions are already answered, so thank you for bringing them up. > > The draft states in the Motivation section: > "The motivation and design of this protocol enhancement is tied to the DNS > root zone [InterNIC]." > > Your Design Overview states that this will work for zones that are > "relatively stable and have infrequent updates". I think some descriptive > text about the type of zone this RR type attempts to address should be more > clearly spelled out in your Abstract. Noted. > > For the ZONEMD RR Type, where in the registry do the authors think it should > go? While some of that falls on the Expert Review process, I think the > document authors should capture their rationale in the document. If the > proposed RR Type is greater than 256 (which I think it does), it does not > appear to require a Standards Track document, just Expert Review. Thanks. Is there a proper way to word such a request? Looking at RFC6895 I'm not seeing a real difference in the way that ranges "<=127" and ">=256" are described. > > I ask this since the document is listed as "Standards Track" and the document > is narrowly scoped to focus on the Root Zone. Additionally the document > states: "This specification is OPTIONAL to implement by both publishers and > consumers of zone file data." This appears to be contradictory to me, but > hopefully someone can illuminate me. > > I ask all of this because we have seen the working group start to push back > on similarly scoped Proposed Standards (kskroll-sentinel). > > Though I do find it amusing that you use "The Camel" as the excuse for such a > limited scope use case, even while requesting a Proposed Standard! I can accept that Standards Track is the wrong choice here. Chalk it up to my naïveté. I suppose Experimental would be more appropriate? DW smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
No, not really - you couldn't do NSEC3 with TXT, for example. Or DNAME, or ANY, or lots of things. I'm just using "could I implement this with TXT?" as a proxy for whether it's a major change to the way the DNS works, or just a thing we can move forward on with expert review. Ah. I gather the question is whether the record has semantics beyond just serving it, like DNAME or the proposed BULK, or it's just another record with no special handling. I think we agree this is clearly the latter, since any specialness is outside the DNS query/response protocol. 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] One Chair's comments on draft-wessels-dns-zone-digest
On Mon, Jul 30, 2018 at 11:03:25AM +1000, Mark Andrews wrote: > Actually it needs to be a type code. How do you hash the TXT RRset and > RRSIG(TXT) RRset when you need to modify both of them after computing the > hash? You need to be able to cleanly exclude the records from the ZONEMD / > XHASH calculations but have a indication that it is present in the zone > (NSEC/NSEC3 bit map). You omit the relevant TXT rrset (_zonehash./TXT, or whatever) when computing the hash for the remainder of the zone. Using a type code is obviously more convenient, but I could implement a zone verification hash without it and so could you. SO, ZONEMD only needs expert review. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
On Sun, Jul 29, 2018 at 09:26:19PM -0400, John Levine wrote: > Well, heck, we could do the whole DNS with TXT records. No, not really - you couldn't do NSEC3 with TXT, for example. Or DNAME, or ANY, or lots of things. I'm just using "could I implement this with TXT?" as a proxy for whether it's a major change to the way the DNS works, or just a thing we can move forward on with expert review. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
From: Tim Wicinski Date: 2018-07-30 10:11 To: John Levine CC: Evan Hunt; dnsop Subject: Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest > > I had spent some time looking the draft over and realizing it was marked > standards track, and I think it would be easier to adopt for the the > specific use case if > it wasn't standards track. > > And, why not combine zone-digest with 7706bis? > It seems to be a good try. Jiankang Yao___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
I agreee John.We have plenty of RR Types to hand out. especially at the upper end On Sun, Jul 29, 2018 at 10:30 PM, John R Levine wrote: > Sorry, if that's what it sounded like. I also think it's worth > considering. My point is that if it's worth trying, we should give it an > rrtype and not screw around with overloaded TXT records. It's not like > we're in any immediate danger of running out of rrtypes. > > R's, > John > > > My email wasn't a statement that I don't think the work is relevant. It >> seems that interesting enough for the WG that there are >> two use cases: 1) the root zone; and 2) everything else. >> >> I had spent some time looking the draft over and realizing it was marked >> standards track, and I think it would be easier to adopt for the the >> specific use case if >> it wasn't standards track. >> >> And, why not combine zone-digest with 7706bis? >> >> Tim >> >> On Sun, Jul 29, 2018 at 9:26 PM, John Levine wrote: >> >> In article <20180730002348.ga41...@isc.org> you write: >>> A good point. Technically, I don't think there's anything in ZONEMD that couldn't be implemented with TXT; using a dedicated rrtype for the purpose is mere convenience. >>> >>> Well, heck, we could do the whole DNS with TXT records. But if it >>> were a TXT record, it'd either need a reserved prefix name or a >>> reserved string in the record to say what it is. As Mark noted, that >>> makes calculating the hash a lot more fiddly. >>> >> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
Sorry, if that's what it sounded like. I also think it's worth considering. My point is that if it's worth trying, we should give it an rrtype and not screw around with overloaded TXT records. It's not like we're in any immediate danger of running out of rrtypes. R's, John My email wasn't a statement that I don't think the work is relevant. It seems that interesting enough for the WG that there are two use cases: 1) the root zone; and 2) everything else. I had spent some time looking the draft over and realizing it was marked standards track, and I think it would be easier to adopt for the the specific use case if it wasn't standards track. And, why not combine zone-digest with 7706bis? Tim On Sun, Jul 29, 2018 at 9:26 PM, John Levine wrote: In article <20180730002348.ga41...@isc.org> you write: A good point. Technically, I don't think there's anything in ZONEMD that couldn't be implemented with TXT; using a dedicated rrtype for the purpose is mere convenience. Well, heck, we could do the whole DNS with TXT records. But if it were a TXT record, it'd either need a reserved prefix name or a reserved string in the record to say what it is. As Mark noted, that makes calculating the hash a lot more fiddly. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
Joe My email wasn't a statement that I don't think the work is relevant. It seems that interesting enough for the WG that there are two use cases: 1) the root zone; and 2) everything else. I had spent some time looking the draft over and realizing it was marked standards track, and I think it would be easier to adopt for the the specific use case if it wasn't standards track. And, why not combine zone-digest with 7706bis? Tim On Sun, Jul 29, 2018 at 9:26 PM, John Levine wrote: > In article <20180730002348.ga41...@isc.org> you write: > >A good point. Technically, I don't think there's anything in ZONEMD that > >couldn't be implemented with TXT; using a dedicated rrtype for the purpose > >is mere convenience. > > Well, heck, we could do the whole DNS with TXT records. But if it > were a TXT record, it'd either need a reserved prefix name or a > reserved string in the record to say what it is. As Mark noted, that > makes calculating the hash a lot more fiddly. > > ___ > 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] One Chair's comments on draft-wessels-dns-zone-digest
In article <20180730002348.ga41...@isc.org> you write: >A good point. Technically, I don't think there's anything in ZONEMD that >couldn't be implemented with TXT; using a dedicated rrtype for the purpose >is mere convenience. Well, heck, we could do the whole DNS with TXT records. But if it were a TXT record, it'd either need a reserved prefix name or a reserved string in the record to say what it is. As Mark noted, that makes calculating the hash a lot more fiddly. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
> On 30 Jul 2018, at 10:23 am, Evan Hunt wrote: > > On Sun, Jul 29, 2018 at 05:42:04PM -0400, Joe Abley wrote: >> I also agree with Tim's observation the other day that if this is just a >> new RRType, then expert review is all that is procedurally required and >> it'd be a generous extension of what is required to document the >> implementation and use of the new RRType in the RFC series. > > A good point. Technically, I don't think there's anything in ZONEMD that > couldn't be implemented with TXT; using a dedicated rrtype for the purpose > is mere convenience. Actually it needs to be a type code. How do you hash the TXT RRset and RRSIG(TXT) RRset when you need to modify both of them after computing the hash? You need to be able to cleanly exclude the records from the ZONEMD / XHASH calculations but have a indication that it is present in the zone (NSEC/NSEC3 bit map). > -- > 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] One Chair's comments on draft-wessels-dns-zone-digest
On Sun, Jul 29, 2018 at 05:42:04PM -0400, Joe Abley wrote: > I also agree with Tim's observation the other day that if this is just a > new RRType, then expert review is all that is procedurally required and > it'd be a generous extension of what is required to document the > implementation and use of the new RRType in the RFC series. A good point. Technically, I don't think there's anything in ZONEMD that couldn't be implemented with TXT; using a dedicated rrtype for the purpose is mere convenience. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
On Jul 29, 2018, at 17:13, Florian Weimer wrote: > * Tim Wicinski: > >> For the ZONEMD RR Type, where in the registry do the authors think it >> should go? While some of that falls on the Expert Review process, I think >> the document authors should capture their rationale in the document. If >> the proposed RR Type is greater than 256 (which I think it does), it does >> not appear to require a Standards Track document, just Expert Review. > > There is some talk in the draft about blocking ZONEMD queries through > recursive resolvers, which wiuld put it into the meta RR space, I > think. > > (But I disagree that there wouldn't be a loss of functionality—if the > ZONEMD record contained the size of the zone, clients might want to > query it, verify its signature, and only download the specified number > of bytes.) I agree with that use-case. I also don't see a compelling reason to complicate the DNS protocol by specifying that QTYPE=ZONEMD needs special handling. That's camel territory as I think Jinmei expresed concern over the other day; better just to document the RRType and let the DNS be the DNS. I also agree with Tim's observation the other day that if this is just a new RRType, then expert review is all that is procedurally required and it'd be a generous extension of what is required to document the implementation and use of the new RRType in the RFC series. Such a document would only need to be an informational and could plausibly be independent stream or AD-sponsored if it doesn't fit the charter or is otherwise unpalatable to the working group. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
* Tim Wicinski: > For the ZONEMD RR Type, where in the registry do the authors think it > should go? While some of that falls on the Expert Review process, I think > the document authors should capture their rationale in the document. If > the proposed RR Type is greater than 256 (which I think it does), it does > not appear to require a Standards Track document, just Expert Review. There is some talk in the draft about blocking ZONEMD queries through recursive resolvers, which wiuld put it into the meta RR space, I think. (But I disagree that there wouldn't be a loss of functionality—if the ZONEMD record contained the size of the zone, clients might want to query it, verify its signature, and only download the specified number of bytes.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
