Re: [dns-operations] cool idea regarding root zone inviolability
On Mon, Dec 1, 2014 at 6:13 PM, Paul Vixie p...@redbarn.org wrote: Paul Vixie p...@redbarn.org Sunday, November 30, 2014 2:29 PM why? (your use case is not obvious from what you've written.) ... Chuck Anderson c...@wpi.edu Monday, December 01, 2014 7:09 AM Silent on-disk corruption. It happens, and it would be nice to be able to detect that. if you're concerned about operating system or hardware or network errors, then i assume you're also concerned about them hitting your name server executable, in which case you'll be running a file system like ZFS that catches these things. if you're concerned about malevolent on-disk editing, then i assume you're running something like tripwire to snapshot with secure hashes every file in your operating system, and that it will have hooks to manage and monitor the zone files as well. either way i'm not seeing a unique has to be done with an in-zone signature situation here. It's not necessarily a has to be done with an in-zone signature, but doing it with an in-zone signature is: A: easy B: convenient C: I have a single blob I can validate. If you are concerned about malevolent on-disk editing and OS issues, you can run ZFS and tripwire to snapshot with secure hashes every file *as well as this. Using the root-zone as an example, currently if I want to validate the zone I do: wkumari-macbookpro1:root-zone wkumari$ wget -q ftp://ftp.internic.net/domain/root.zone wkumari-macbookpro1:root-zone wkumari$ wget -q ftp://ftp.internic.net/domain/root.zone.sig wkumari-macbookpro1:root-zone wkumari$ gpg --verify root.zone.sig root.zone gpg: Signature made Mon Dec 1 13:53:30 2014 EST using DSA key ID 4150E298 gpg: Good signature from Registry Administrator ns...@verisign-grs.com (entertainingly enough I trust 4150E298 because it was signed on 2013-02-11 by Larson, Matt /o=VERISIGN/ou=VA-EAST/cn=Recipients/cn=mlarson) Clearly detached signatures *do* work, but if I happened to get the root.zone at 6:52:59PM and the root.zone.sig file at 6:53:01PM I'd have an issue (noting that the file time stamp is 6:53:00 PM) I now have an issue. This also gets finicky if I try and keep multiple copies of the zones for historical reasons, to be able to show that what I served was what I got, etc. Yes, having version numbers on the files and detached sigs is doable (or simply retrying if I get a validation failure, etc) but I cannot see the downside to including it in the zone as well - if you dislike the ZONESIG RR (just made up name) you can simply choose not to check it. Similarly, if someone emails me example.com.db and says Please serve this zonefile, I signed it with my GPG key, and the signature is 0xdeadbeef...cafe (or I attached example.com.db.sig) I have a bunch more places where things could go wrong, including the obvious forgetting to attach both files, having a signature for serial 2014120117 and the zone contents for serial 2014120142, etc. Having Here is the signed zone example.com.db and passing that to load_and_validate_zone.sh or 'rndc addzone --validate example.com. is (IMO) much less error prone. I think that this is similar to how, when you get a PGP signed email you get the signature in the same message, and not one email saying Foo Bar Baz and then a second email with a signature for the first message. W -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- 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 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
On Sun, Nov 30, 2014 at 02:29:15PM -0800, Paul Vixie wrote: Doug Barton mailto:do...@dougbarton.us Sunday, November 30, 2014 1:21 PM ... We still need a way to verify the entire contents of the zone however. This goes beyond just transfers, it would be nice to be able to verify that a zone downloaded using a method other than transfers is both accurate and complete. why? (your use case is not obvious from what you've written.) are you trying to ensure that errors that creep by TCP's error checking or that result from silent sending-side failures where both the starting and ending SOA are present but the middle is corrupt? or are you trying to ensure that a tertiary server can't be lied to by its secondary server? Silent on-disk corruption. It happens, and it would be nice to be able to detect that. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
Paul Vixie mailto:p...@redbarn.org Sunday, November 30, 2014 2:29 PM why? (your use case is not obvious from what you've written.) ... Chuck Anderson mailto:c...@wpi.edu Monday, December 01, 2014 7:09 AM Silent on-disk corruption. It happens, and it would be nice to be able to detect that. if you're concerned about operating system or hardware or network errors, then i assume you're also concerned about them hitting your name server executable, in which case you'll be running a file system like ZFS that catches these things. if you're concerned about malevolent on-disk editing, then i assume you're running something like tripwire to snapshot with secure hashes every file in your operating system, and that it will have hooks to manage and monitor the zone files as well. either way i'm not seeing a unique has to be done with an in-zone signature situation here. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
Florian Weimer mailto:f...@deneb.enyo.de Sunday, November 30, 2014 2:08 AM Wouldn't be a first to step to cover root server *operators* (and root DNS server sites) to audits, lift them out of obscurity, and introduce some form of accountability? accountability may be too strong a word for the art of the possible in this case. a long time ago someone from icann (who is now long gone) presented me (as isc president) with a proposed MoU that allowed either party unilateral termination without cause, and specified that f-root's address block (192.5.4.0/23) would become icann's property if the agreement were ever terminated. after a few hours of wtf? from both sides, i ended negotiations around the MoU and determined that no root name server operator could ever be accountable to the icann corrupt-o-thon, and that our accountability had to be much broader. years later, using a different negotiator on the icann side, an MoU was negotiated between icann and isc. it's online, see reference #8 at http://icannwiki.com/ISC, noting that all of the Key People listed on that page have moved on from ISC, but their current team is excellent. additional anti-obscurity measures such as audits and additional MoU's are worth discussing. the root server operators now have a very cordial relationship to ICANN and they provide the core of the RSSAC. see https://www.icann.org/resources/pages/rssac-4c-2012-02-25-en for some contact info on getting started with that sort of initiative. It's not a bad idea to make sure that the data that goes into the root system isn't compromised, but right now, anyone can already review that, and there is even some public documentation for the update process. Contrast this with the situation on the operator side, where important information such as site selection criteria is only available under NDA (if at all). each rootop has its own method of site selection. this is both an anti-capture mechanism and a diversity-assurance mechanism. i believe that most rootops would be willing to speak on the record about their site selection criteria if asked, and without an NDA. note that i'm speaking of my beliefs, and not as a spokesman for any rootop other than F (before) and C (now), because the rootops as an aggregate entity have no spokesperson. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
Doug Barton mailto:do...@dougbarton.us Sunday, November 30, 2014 1:21 PM ... We still need a way to verify the entire contents of the zone however. This goes beyond just transfers, it would be nice to be able to verify that a zone downloaded using a method other than transfers is both accurate and complete. why? (your use case is not obvious from what you've written.) are you trying to ensure that errors that creep by TCP's error checking or that result from silent sending-side failures where both the starting and ending SOA are present but the middle is corrupt? or are you trying to ensure that a tertiary server can't be lied to by its secondary server? I'm sensitive to your expectation that non-transfer methods should provide their own security, and your argument that every new line of code adds more fragility. However I do see the appeal of a standardized way of demonstrating that a given zone is what it should be. i'm not going to say whether i see appeal. rather, i'll ask you, what feature you want to add, how will it make the domain name system better in some measurable way like performance, resilience, uptime, or correctness, and why is it better than at least one and preferably two alternatives you can think of, and also enough better than the status quo to be worth the cost of its additional systemic complexity? in other words can you do some engineering economics here rather than asserting and then periodically re-asserting that some feature would be nice or that you see appeal? -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
On Nov 28, 2014, at 02:07 , Paul Vixie p...@redbarn.org wrote: is there some reason why an updated sig(0) is not a solution to this? People move zone data around using mechanisms other than *XFR (scp, database replication, etc.). A signature on the complete zone, as part of the zone, also covers those mechanisms. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
On Sat, Nov 29, 2014 at 01:15:48PM -0800, Paul Vixie wrote: can you tell me the use case for having this signature be in-band? An out-of-band signature can only cover an out-of-band transfer. An in-band signature could cover both kinds. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
Evan Hunt mailto:e...@isc.org Saturday, November 29, 2014 2:00 PM An out-of-band signature can only cover an out-of-band transfer. An in-band signature could cover both kinds. well, sure, but at the expense of the secondary server having to read every byte of the transferred zone contents, which is currently unnec'y for servers using an mmap'd file that they only access sparsely and at need. (whereas the prospective out-of-band transfer method already has to touch every byte of the zone contents, and could therefore verify a signature for free.) this matters, because if the secondary server is going to have to iterate through the whole zone after loading it, it might as well just verify the DNSSEC signatures and NSEC chain. that wouldn't test for validity of the zone, but it would be a consistency check of the same depth as any zone-level signature could offer. and what's better is, incremental changes via IXFR or UPDATE could then be tested incrementally. here, i'm specifically thinking of zones so large that touching every byte of their content is a multiple-minutes cost. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
On Nov 29, 2014, at 17:57 , Paul Vixie p...@redbarn.org wrote: here, i'm specifically thinking of zones so large that touching every byte of their content is a multiple-minutes cost. Those zones are relatively rare though, and reading a randomly-written mmaped file isn’t a common name server implementation. That seems to me to be optimizing for an edge case at the expense of the common case. Zones which fall into that rather narrow edge case can simply not use this proposed signature. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
Matthew Pounsett mailto:m...@conundrum.com Saturday, November 29, 2014 3:03 PM Those zones are relatively rare though, and reading a randomly-written mmaped file isn't a common name server implementation. That seems to me to be optimizing for an edge case at the expense of the common case. Zones which fall into that rather narrow edge case can simply not use this proposed signature. if we were discussing an in-band protocol signal, then an applicability statement along those lines would make sense to me. since we're discussing an out-of-band zone transfer, i'm trying to understand how we can specify anything at all about how it behaves, beyond a recommendation that if out-of-band transfer is used, then zone integrity checking should be done. notefully: rsync's use of TCP is, to me, strong enough to protect zone integrity. in other words, for in-band transfers (AXFR, IXFR, and to some extent UPDATE), the obvious in-band integrity check would be (a) also in-band, (b) incremental, and (c) dnssec-based. there would be no benefit to the in-band case from paying the cost of maintaining an in-band zone signature, even if someone knows a way to incrementally update a secure hash after an IXFR or UPDATE. whereas in the out-of-band transfer case, the out-of-band transferee is going to have to touch every byte and is the obvious actor to burden with integrity checking, but, if we want the secondary server to do integrity checking after an AXFR or IXFR, it should be zone walking, not just comparing some as-yet-nonexistent secure-yet-updateable zone-level hash. every bit of logic and arithmetic we add to the world's dns implementations increases DNS's attack surface due to the inevitability of bugs. before we add something like a zone-level hash, i'd like us all to be sure it solves a problem in a uniquely excellent way. for example, dan kaminsky proposed several years ago that a stub be able to request, by EDNS, the full RRSIG/DNSKEY/DS chain from the qname upward to some specified TA, to permit stub validation without requiring a stub cache or to spend many round trips on a validation. that would be complexity worth adding, because it has a clear use case and it enables something that's impractical today (last-mile validation). it's a terrible loss to us all that the roads not taken in DNSSEC weren't recorded as well as the roads taken. zone-level signatures were proposed, debated, and not merely failed to find consensus in favour, but actually found consensus against. now we're starting over without the benefit of knowing why this was deliberately not put into DNSSEC in the first place. vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
On Nov 27, 2014, at 8:31 PM, Mark Andrews ma...@isc.org wrote: In message d09d2683.7570%edward.le...@icann.org, Edward Lewis writes: Not meant to rain on the parade (but this sounds like it) - early on In the development of DNSSEC we spent a bit of time on SIG(AXFR) which is exactly what you described. We toyed with it and discarded it. I forget why (which makes this a rain on the parade email) but for a long time afterwards we had series of jokes that ended with that idea is as bad as SIG(AXFR). We being the folks in the lab in the 90’s. ...Perhaps it was an estimation of the workload involved on the servers (to do all the nasty crypto), complications from incremental updates (which were new then). We also wrote servers to verify all records upon (authoritative) load and that was discarded because it took forever to start the server – probably related. Maybe someone else on the list recalls why SIG(AXFR) was killed off. Sorting and hashing a zone is not that expensive for 99.999% of zones even on every dynamic update. Yes, there are some enourmous zones where it is very expensive but they are the exception not the rule. You need to maintain zones in DNSSEC order for NSEC maintainence with Simple Secure UPDATE. Validating every record is expensive and is is unnecessary if you have a hash and a signature over that hash. SIG(AXFR) as documented didn't really do the job. It didn't work well with IXFR or UPDATE. And as most of these are leaf zones with less than 10 RRsets what is the cost difference between comparing NSEC/3 chain with contents and verifying signatures. The only zones that we can justify SIG(*FER) for are large delegation zones, which frequently have high update frequency and limited time to publish the updates. As much as I like the concept of a zone checksum it is hard to maintain for anything but small, infrequently changing zones. If someone wants to define a mechanism fine, but do not expect many to verify except in special cases. Olafur ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
In message 54781f2a.4050...@redbarn.org, Paul Vixie writes:
Mark Andrews mailto:ma...@isc.org
Thursday, November 27, 2014 7:22 PM
if your master server sends you a final (matching) SOA not having
stuffed its end of the tcp session with all the right records in
between, or if your TCP is allowing end-to-end badness without its CRC32
detecting same at the tcp segment level, then you have bigger worries.
Given named does sanity checks when apply ixfr deltas and they
actually have been known to trigger, knowing that you have a complete
zone after applying a ixfr would be a good thing.
...
... Whether is is TSIG or these records you are using a
cryptographic hash + a key to ensure that all the glue is correct
and you are trusting the generator of that hash and signer to be
doing the correct thing. And the key is tied back to a trust anchor
directly or indirectly.
is there some reason why an updated sig(0) is not a solution to this?
SIG(0) is hop by hop.
As to whether you iterate or not also depends on the trust anchors
installed, whether the keys are RFC 5011 managed or similar. Having
a managed trust anchor for every zone isn't a be deal.
adding RFC 5011 support to a non-mixed-mode (authority only) server
would be a very big deal. so, that's an area of strong disagreement if
we discuss it further.
and the whole trigger for this discussion was a mixed mode server with
a local copy of the root zone.
is there a specification for how mixed-mode servers will validate data
they don't fetch? as in, you really are making a recommendation for
zone-level validation that would then permit zone-local data to be used
in forming responses to recursive queries in a mixed-mode server? i'd
like to hear the details of that, because while DNSSEC talks about how
to validate data you receive in queries, it does not talk about how to
validate data you've received in zone transfers.
Well the early DNSSEC RFC did have the concept of validating the
zone transfer. As for local zone data being returned to recursive
queries the nameserver is broken if it doesn't do so.
i argue that it's not a
trivial exercise, even if an updated sig(0) could be used to validate
zone transfers. (i remember more than olafur claims to, concerning why
we don't have zone-level signatures today. it's related to why glue is
not signed and does not need to be signed, and it comes from security
theory not dns theory.)
Really all records should be signed so you reject on reception
rather than after the fact. Most recursive nameservers won't recover
from spoofed glue if you can manage to insert it which leads to a
DoS. We detect that we got misdirected. Improvef hop-by-hop
security however can deal with that or we can add glue signatures
(covers delegating NS, A and ) though it will increase delegation
centric zone sizes and OPTOUT would be pointless.
As for adding RFC 5011 support for the zones it serves, a authorative
server has all the data it needs to do that as part of its normal
roll of being a authoritative server. It's only a matter or reading
what it is serving to others.
i don't think this is true. rfc 5011 assumes that you're starting with a
known-good TA and that you'll use this to validate subsequent changes to
that TA. those starting conditions are not in effect on any
authoritative-only server i have administered.
So what? Do you think a adminstrator is incapable of adding a
trusted key along with the masters to transfer from when configuring
a slave?
zone . {
type slave;
managed-trusted-key ;
.
};
--
Paul Vixie
--010306050600050904090007
Content-Type: multipart/related;
boundary=090301010501070707010608
--090301010501070707010608
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
htmlhead
meta content=text/html; charset=ISO-8859-1 http-equiv=Content-Type
/headbody text=#00 bgcolor=#FFbr
br
blockquote style=border: 0px none;
cite=mid:20141128032205.780762479...@rock.dv.isc.org type=cite
div style=margin:30px 25px 10px 25px; class=__pbConvHrdiv
style=display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px div
style=display:table-cell;vertical-align:middle;padding-right:6px;img
photoaddress=ma...@isc.org photoname=Mark Andrews
src=cid:part1.06060702.02070404@redbarn.org
name=compose-unknown-contact.jpg width=25px height=25px/div div
style=display:table-cell;white-space:nowrap;vertical-align:middle;width:100%
a moz-do-not-send=true href=mailto:ma...@isc.org;
style=color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;Mark Andrews/a/div div
style=display:table-cell;white-space:nowrap;vertical-align:middle;
font color=#9FA2A5span style=padding-left:6pxThursday,
November 27, 2014 7:22 PM/span/font/div/div/div
div
Re: [dns-operations] cool idea regarding root zone inviolability
Mark Andrews mailto:ma...@isc.org
Friday, November 28, 2014 12:57 AM
In message 54781f2a.4050...@redbarn.org, Paul Vixie writes:
Mark Andrews mailto:ma...@isc.org
Thursday, November 27, 2014 7:22 PM
if your master server sends you a final (matching) SOA not having
stuffed its end of the tcp session with all the right records in
between, or if your TCP is allowing end-to-end badness without its CRC32
detecting same at the tcp segment level, then you have bigger worries.
Given named does sanity checks when apply ixfr deltas and they
actually have been known to trigger, knowing that you have a complete
zone after applying a ixfr would be a good thing.
...
... Whether is is TSIG or these records you are using a
cryptographic hash + a key to ensure that all the glue is correct
and you are trusting the generator of that hash and signer to be
doing the correct thing. And the key is tied back to a trust anchor
directly or indirectly.
is there some reason why an updated sig(0) is not a solution to this?
SIG(0) is hop by hop.
i was responding to your examples. if you want end to end zone
signatures so that a tertiary server can know that the secondary isn't
lying to it, then of course SIG(0) (and TSIG) aren't useful.
is there a specification for how mixed-mode servers will validate data
they don't fetch? as in, you really are making a recommendation for
zone-level validation that would then permit zone-local data to be used
in forming responses to recursive queries in a mixed-mode server? i'd
like to hear the details of that, because while DNSSEC talks about how
to validate data you receive in queries, it does not talk about how to
validate data you've received in zone transfers.
Well the early DNSSEC RFC did have the concept of validating the
zone transfer.
i think it's gone from current RFC's for a very good reason.
As for local zone data being returned to recursive
queries the nameserver is broken if it doesn't do so.
in this scenario, it's possible that noone is validating the signatures
(or the NSEC's.) this sounds unspecified. can you explain (with
reference to 4034 or 4035, or later work) what you mean by broken? i
do not know that the current DNSSEC spec explains what a mixed-mode
server should do about validation. if you do, i hope you will point it out.
As for adding RFC 5011 support for the zones it serves, a authorative
server has all the data it needs to do that as part of its normal
roll of being a authoritative server. It's only a matter or reading
what it is serving to others.
i don't think this is true. rfc 5011 assumes that you're starting with a
known-good TA and that you'll use this to validate subsequent changes to
that TA. those starting conditions are not in effect on any
authoritative-only server i have administered.
So what? Do you think a adminstrator is incapable of adding a
trusted key along with the masters to transfer from when configuring
a slave?
zone . {
type slave;
managed-trusted-key ;
.
};
i thought you said has all the data it needs, not it could be given
all the data it needs.let's talk about how the transition to
managed-trusted-key would work.
since we're talking about RFC 5011 here, which covers any zone's TA not
just the root zone's TA, the initial key would have to either be entered
as configuration data, or fetched and validated against an ancestor TA.
in the later case, the authority server would be acting as a validating
stub resolver for the purpose of fetching and validating its way
down-chain from the TA it has (presumably the root pubkey) to the TA
it's establishing.
i don't view those as trivial steps, but i agree with what i think you
said, which was that if we could maintain each secondary zone's TA
reliably, and we could validate every AXFR and IXFR we receive, then we
could mix local authority data into RD=1 responses in a mixed mode
server. i fear that this would make DNSSEC more fragile for the public
internet, but it sounds like it could at least be made to work in the lab.
--
Paul Vixie
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
On Fri, 28 Nov 2014, Mark Andrews wrote: Sorting and hashing a zone ... is not mathematically necessary. As a simple counterexample, XOR is commutative and associative: it doesn't matter the order you XOR multiple blocks in. Not saying XOR is the One True Way, just that implementation details like that are probably a distraction at this point. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
Fred Morris mailto:m3...@m3047.net Friday, November 28, 2014 3:07 PM ... is not mathematically necessary. As a simple counterexample, XOR is commutative and associative: it doesn't matter the order you XOR multiple blocks in. Not saying XOR is the One True Way, just that implementation details like that are probably a distraction at this point. any zone-level signature has to be crypto-authentic. XOR is too easy to fix up, as in, add or delete your desired changes, compare the new checksum to the old one, then add a TXT RR that causes the new checksum to match the old one. so, i'm not in favour of zone-level signatures per se, but if they're coming, then marka@isc's characterization of them as sorting and hashing is mathematically nec'y. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
Patrik, On Nov 26, 2014, at 10:40 PM, Patrik Fältström p...@frobbit.se wrote: FWIW, I have been working on this for a while with the Diplo foundation, and I am happy to answer questions (and of course listen to concerns). It is an interesting idea, but I don't get how it would work. I asked Jovan back when he initially proposed it, but never heard back. Is the theory behind this that governments around the world would enter into some sort of treaty or some other formally binding vehicle that would make the root zone inviolable? What would be the sanctions should the holder of the root zone (whoever it might be) ignore the inviolability of the root zone and how would they be enforced? How is that going to work given (e.g.) the US hasn't even been able to ratify the Treaty of the Sea and internal domestic politics will generally override any international agreement at politicians' whim? Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
Having worked on solas at Intl maritime org, I agree with David. There are many parallels to that space and domain name space. We should learn from that experience. Rick Sent from my iPhone On Nov 27, 2014, at 11:19, David Conrad d...@virtualized.org wrote: Patrik, On Nov 26, 2014, at 10:40 PM, Patrik Fältström p...@frobbit.se wrote: FWIW, I have been working on this for a while with the Diplo foundation, and I am happy to answer questions (and of course listen to concerns). It is an interesting idea, but I don't get how it would work. I asked Jovan back when he initially proposed it, but never heard back. Is the theory behind this that governments around the world would enter into some sort of treaty or some other formally binding vehicle that would make the root zone inviolable? What would be the sanctions should the holder of the root zone (whoever it might be) ignore the inviolability of the root zone and how would they be enforced? How is that going to work given (e.g.) the US hasn't even been able to ratify the Treaty of the Sea and internal domestic politics will generally override any international agreement at politicians' whim? Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
... and Mark Andrews, Paul Hofmann, Paul Wouters, myself and a few others (who I embarrassing enough have forgotten) are planning on writing a zone signature draft (I have an initial version in an edit buffet). The 50,000 meter view is: Sort all the records in canonical order (including glue) Cryptographicly sign this Stuff the signature in a record This allows you to verify that you have the full and complete zone (.de...) and that it didn't get corrupted in transfer. This solves a different, but related issue. Hope to finally get off my butt and post -00 soon. W On Thursday, November 27, 2014, Richard Lamb richard.l...@icann.org wrote: Having worked on solas at Intl maritime org, I agree with David. There are many parallels to that space and domain name space. We should learn from that experience. Rick Sent from my iPhone On Nov 27, 2014, at 11:19, David Conrad d...@virtualized.org javascript:; wrote: Patrik, On Nov 26, 2014, at 10:40 PM, Patrik Fältström p...@frobbit.se javascript:; wrote: FWIW, I have been working on this for a while with the Diplo foundation, and I am happy to answer questions (and of course listen to concerns). It is an interesting idea, but I don't get how it would work. I asked Jovan back when he initially proposed it, but never heard back. Is the theory behind this that governments around the world would enter into some sort of treaty or some other formally binding vehicle that would make the root zone inviolable? What would be the sanctions should the holder of the root zone (whoever it might be) ignore the inviolability of the root zone and how would they be enforced? How is that going to work given (e.g.) the US hasn't even been able to ratify the Treaty of the Sea and internal domestic politics will generally override any international agreement at politicians' whim? Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net javascript:; https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net javascript:; https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- 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 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
In message cahw9_ildgnkmervovhhj41fswm6+5yj0tdxrsj17kdhzqty...@mail.gmail.com , Warren Kumari writes: ... and Mark Andrews, Paul Hofmann, Paul Wouters, myself and a few others (who I embarrassing enough have forgotten) are planning on writing a zone signature draft (I have an initial version in an edit buffet). The 50,000 meter view is: Sort all the records in canonical order (including glue) Cryptographicly sign this Stuff the signature in a record This allows you to verify that you have the full and complete zone (.de...) and that it didn't get corrupted in transfer. This solves a different, but related issue. Hope to finally get off my butt and post -00 soon. W Which is similar to RFC 2065, 4.1.3 Zone Transfer (AXFR) SIG except dynamic updates would update the record and it would be in the zone. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
Warren Kumari mailto:war...@kumari.net Thursday, November 27, 2014 1:11 PM ... and Mark Andrews, Paul Hofmann, Paul Wouters, myself and a few others (who I embarrassing enough have forgotten) are planning on writing a zone signature draft (I have an initial version in an edit buffet). The 50,000 meter view is: Sort all the records in canonical order (including glue) Cryptographicly sign this Stuff the signature in a record This allows you to verify that you have the full and complete zone (.de...) and that it didn't get corrupted in transfer. This solves a different, but related issue. would this draft change the setting of the AA bit on an secondary server's responses, or make it unwilling to answer under some conditions? right now there is no dependency, AA is always set. but if we're going to make it conditional, then it should be conditioned on the signatures matching all the way up-chain to a trust anchor, which would require an authority server to also contain a validator and be able to make iterative queries. so, i wonder about the use case for your draft. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
On Thursday, November 27, 2014, Paul Vixie p...@redbarn.org wrote: Warren Kumari javascript:_e(%7B%7D,'cvml','war...@kumari.net'); Thursday, November 27, 2014 1:11 PM ... and Mark Andrews, Paul Hofmann, Paul Wouters, myself and a few others (who I embarrassing enough have forgotten) are planning on writing a zone signature draft (I have an initial version in an edit buffet). The 50,000 meter view is: Sort all the records in canonical order (including glue) Cryptographicly sign this Stuff the signature in a record This allows you to verify that you have the full and complete zone (.de...) and that it didn't get corrupted in transfer. This solves a different, but related issue. would this draft change the setting of the AA bit on an secondary server's responses, or make it unwilling to answer under some conditions? right now there is no dependency, AA is always set. but if we're going to make it conditional, then it should be conditioned on the signatures matching all the way up-chain to a trust anchor, which would require an authority server to also contain a validator and be able to make iterative queries. so, i wonder about the use case for your draft. -- Paul Vixie This allows a slave (or anyone else who wants to validate a zone, e.g a master loading from disk) to know that they have a full and correct zone. This covers things like accidental zone truncation (which has bitten some folk), zone file corruption, etc. if someone hands me a zone somehow (e.g AXFR) and asks me to serve it I'd like a way to make sure it hasn't been accidentally (or intentionally) changed. I'm assuming I'd want my name server software to refuse to load the zone and try retransfer, throw an error, or similar. The signature could be (and the way I'd envisioned it) DNSSEC, so up to a TA, or a manually configured key specific to the zone. W -- 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 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
In message 54779dd0.4070...@redbarn.org, Paul Vixie writes: Warren Kumari mailto:war...@kumari.net Thursday, November 27, 2014 1:11 PM ... and Mark Andrews, Paul Hofmann, Paul Wouters, myself and a few others (who I embarrassing enough have forgotten) are planning on writing a zone signature draft (I have an initial version in an edit buffet). The 50,000 meter view is: Sort all the records in canonical order (including glue) Cryptographicly sign this Stuff the signature in a record This allows you to verify that you have the full and complete zone (.de...) and that it didn't get corrupted in transfer. This solves a different, but related issue. would this draft change the setting of the AA bit on an secondary server's responses, or make it unwilling to answer under some conditions? right now there is no dependency, AA is always set. but if we're going to make it conditional, then it should be conditioned on the signatures matching all the way up-chain to a trust anchor, which would require an authority server to also contain a validator and be able to make iterative queries. so, i wonder about the use case for your draft. -- Paul Vixie Just having a cryptographically strong zone self consistancy check is a big win with IXFR. If that fails you AXFR the zone and try again. For the root zone you don't need a iterative validator as you would have the root as a trust anchor and in general a authoritative server needs a interative resolver for NOTIFY. As to whether you iterate or not also depends on the trust anchors installed, whether the keys are RFC 5011 managed or similar. Having a managed trust anchor for every zone isn't a be deal. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
On Thursday, November 27, 2014, Francisco Obispo fobi...@uniregistry.link wrote: +1 And if someone is already serving the root zone, they can always modify the server to return AA. I'm also wondering about the use case. See above - this has *nothing* to do with setting or not setting AA. This simply allows the entity serving a zone to confirm that they have a complete, uncorrupt, and untampered copy of the zone. Think of it as a cryptographic checksum if you like. Before serving a zone (as a master or slave) I'd like to know it is correct... W Francisco Obispo On Nov 27, 2014, at 1:55 PM, Paul Vixie p...@redbarn.org javascript:_e(%7B%7D,'cvml','p...@redbarn.org'); wrote: postbox-contact.jpg Warren Kumari javascript:_e(%7B%7D,'cvml','war...@kumari.net'); Thursday, November 27, 2014 1:11 PM ... and Mark Andrews, Paul Hofmann, Paul Wouters, myself and a few others (who I embarrassing enough have forgotten) are planning on writing a zone signature draft (I have an initial version in an edit buffet). The 50,000 meter view is: Sort all the records in canonical order (including glue) Cryptographicly sign this Stuff the signature in a record This allows you to verify that you have the full and complete zone (.de...) and that it didn't get corrupted in transfer. This solves a different, but related issue. would this draft change the setting of the AA bit on an secondary server's responses, or make it unwilling to answer under some conditions? right now there is no dependency, AA is always set. but if we're going to make it conditional, then it should be conditioned on the signatures matching all the way up-chain to a trust anchor, which would require an authority server to also contain a validator and be able to make iterative queries. so, i wonder about the use case for your draft. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net javascript:_e(%7B%7D,'cvml','dns-operations@lists.dns-oarc.net'); https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- 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 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
If somebody said to me: lets have a canonicalize() function which makes a deterministic byte-stream of the state of a zone, and then calculate a checksum over it I'd struggle to say that was a bad idea. If you have a transform which takes updates in any kind, AXFR or IXFR and can then re-canonicalize and test the zone state against a known published record of the zone state, whats the downside? I understand there is an element of redundency in the scheme, against what DNSSEC can alteady do at the RR level, but I think from whats been said, and what is being said about schemes to provide for re-distribution of the root, this makes a lot of sense. The history only informs the present, it doesn't have to determine it. The statement about 'learning from history, doomed to repeat it' is not meant to say you cannot re-try things previously considered and rejected. It means you need to be aware of them. -G On 28 November 2014 at 07:18, Edward Lewis edward.le...@icann.org wrote: After reading on… I think the rationale of killing SIG(AXFR) was that DNSSEC is there to protect the relying party and not the manager of the zone. I.e., a relying party only cared about the data it received pertinent to the query it issued. This made the building the chain of trust as efficiently as possible paramount. Forking into zone replication was a design distraction. That’s not the reason SIG(AXFR) failed, that’s the reason we didn’t try harder to accomplish it. DNSSEC did not exist to make managing DNS better[0] (I.e., protect against zone truncation), so taking time to do that was hindering the primary purpose of answering questions with proof of authenticity and integrity. [0] Joke and snicker if you must. Yes DNSSEC today makes running today’s DNS harder, keep in mind that the state of the system in the 90’s was so bad that it would not have survived with the major rewrites DNSSEC development caused. DNSSEC didn’t have a real good foundation to build upon. On 11/27/14, 17:48, Warren Kumari war...@kumari.net wrote: On Thursday, November 27, 2014, Francisco Obispo fobi...@uniregistry.link wrote: +1 And if someone is already serving the root zone, they can always modify the server to return AA. I'm also wondering about the use case. See above - this has *nothing* to do with setting or not setting AA. This simply allows the entity serving a zone to confirm that they have a complete, uncorrupt, and untampered copy of the zone. Think of it as a cryptographic checksum if you like. Before serving a zone (as a master or slave) I'd like to know it is correct... W Francisco Obispo On Nov 27, 2014, at 1:55 PM, Paul Vixie p...@redbarn.org wrote: postbox-contact.jpg Warren Kumari Thursday, November 27, 2014 1:11 PM ... and Mark Andrews, Paul Hofmann, Paul Wouters, myself and a few others (who I embarrassing enough have forgotten) are planning on writing a zone signature draft (I have an initial version in an edit buffet). The 50,000 meter view is: Sort all the records in canonical order (including glue) Cryptographicly sign this Stuff the signature in a record This allows you to verify that you have the full and complete zone (.de...) and that it didn't get corrupted in transfer. This solves a different, but related issue. would this draft change the setting of the AA bit on an secondary server's responses, or make it unwilling to answer under some conditions? right now there is no dependency, AA is always set. but if we're going to make it conditional, then it should be conditioned on the signatures matching all the way up-chain to a trust anchor, which would require an authority server to also contain a validator and be able to make iterative queries. so, i wonder about the use case for your draft. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- 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 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
In message d09d2683.7570%edward.le...@icann.org, Edward Lewis writes: Not meant to rain on the parade (but this sounds like it) - early on In the development of DNSSEC we spent a bit of time on SIG(AXFR) which is exactly what you described. We toyed with it and discarded it. I forget why (which makes this a rain on the parade email) but for a long time afterwards we had series of jokes that ended with that idea is as bad as SIG(AXFR). We being the folks in the lab in the 90âs. ...Perhaps it was an estimation of the workload involved on the servers (to do all the nasty crypto), complications from incremental updates (which were new then). We also wrote servers to verify all records upon (authoritative) load and that was discarded because it took forever to start the server â probably related. Maybe someone else on the list recalls why SIG(AXFR) was killed off. Sorting and hashing a zone is not that expensive for 99.999% of zones even on every dynamic update. Yes, there are some enourmous zones where it is very expensive but they are the exception not the rule. You need to maintain zones in DNSSEC order for NSEC maintainence with Simple Secure UPDATE. Validating every record is expensive and is is unnecessary if you have a hash and a signature over that hash. SIG(AXFR) as documented didn't really do the job. It didn't work well with IXFR or UPDATE. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
summary: no worries, this isn't what i thought it was. details below. Warren Kumari mailto:war...@kumari.net Thursday, November 27, 2014 2:20 PM This allows a slave (or anyone else who wants to validate a zone, e.g a master loading from disk) to know that they have a full and correct zone. This covers things like accidental zone truncation (which has bitten some folk), if your master server sends you a final (matching) SOA not having stuffed its end of the tcp session with all the right records in between, or if your TCP is allowing end-to-end badness without its CRC32 detecting same at the tcp segment level, then you have bigger worries. zone file corruption, etc. if someone hands me a zone somehow (e.g AXFR) and asks me to serve it I'd like a way to make sure it hasn't been accidentally (or intentionally) changed. for a dnssec signed zone the only way to do that is to zone-walk and validate. belt-and-suspenders isn't a good model for axfr/ixfr, because complexity, and because the zone signature would have to be incrementally maleable and so not one-way or crypto-authentic, because update. I'm assuming I'd want my name server software to refuse to load the zone and try retransfer, throw an error, or similar. The signature could be (and the way I'd envisioned it) DNSSEC, so up to a TA, or a manually configured key specific to the zone. if this is proposed and adopted, my discussion input will be along the lines of no authority server can every be required to query for anything as part of its operations. just letting you know where DNSSEC ... signature leads to. importantly, you're envisioning this as a new way to fail, but not a new criteria for success. that is, this new signature mechanism is to you a reason to reject an AXFR or IXFR, which would then lead to zone timeout and SERVFAIL unless corrected. that's not a problem. i was worried that this would be used in some way to permit/deny zone data to be used by a mixed-mode server in response to RD=1 queries. that would be a larger kettle of different fish. furthermore: Mark Andrews Thursday, November 27, 2014 2:45 PM Just having a cryptographically strong zone self consistancy check is a big win with IXFR. If that fails you AXFR the zone and try again. if you're trying to make a case for public key TSIG, i'd agree with you, and say, SIG(0) [RFC 2931]. i'd support an rfc 2931-bis effort, as a reviewer and as a contributor. For the root zone you don't need a iterative validator as you would have the root as a trust anchor and in general a authoritative server needs a interative resolver for NOTIFY. if you're arguing that NOTIFY should support DNSSEC by including RRSIG(SOA), i'd agree. but right now there is no TA on root zone slaves, they never query for anything, they never validate anything, they don't speak RFC 5011. and that's a deliberate design decision, not an accident or oversight. As to whether you iterate or not also depends on the trust anchors installed, whether the keys are RFC 5011 managed or similar. Having a managed trust anchor for every zone isn't a be deal. adding RFC 5011 support to a non-mixed-mode (authority only) server would be a very big deal. so, that's an area of strong disagreement if we discuss it further. vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
In message 5477dcc2.8050...@redbarn.org, Paul Vixie writes: summary: no worries, this isn't what i thought it was. details below. Warren Kumari mailto:war...@kumari.net Thursday, November 27, 2014 2:20 PM This allows a slave (or anyone else who wants to validate a zone, e.g a master loading from disk) to know that they have a full and correct zone. This covers things like accidental zone truncation (which has bitten some folk), if your master server sends you a final (matching) SOA not having stuffed its end of the tcp session with all the right records in between, or if your TCP is allowing end-to-end badness without its CRC32 detecting same at the tcp segment level, then you have bigger worries. Given named does sanity checks when apply ixfr deltas and they actually have been known to trigger, knowing that you have a complete zone after applying a ixfr would be a good thing. zone file corruption, etc. if someone hands me a zone somehow (e.g AXFR) and asks me to serve it I'd like a way to make sure it hasn't been accidentally (or intentionally) changed. for a dnssec signed zone the only way to do that is to zone-walk and validate. belt-and-suspenders isn't a good model for axfr/ixfr, because complexity, and because the zone signature would have to be incrementally maleable and so not one-way or crypto-authentic, because update. You can do increment signatures on ranges of names for big zones. This reduces the amount of data that has to be process on a update. Think NSEC with a hash rather than a bitmap. One every hundred / thousands names or so and a final signature over the hash of these. This is similar to how TSIG works on multiple messages. I'm assuming I'd want my name server software to refuse to load the zone and try retransfer, throw an error, or similar. The signature could be (and the way I'd envisioned it) DNSSEC, so up to a TA, or a manually configured key specific to the zone. if this is proposed and adopted, my discussion input will be along the lines of no authority server can every be required to query for anything as part of its operations. just letting you know where DNSSEC ... signature leads to. importantly, you're envisioning this as a new way to fail, but not a new criteria for success. that is, this new signature mechanism is to you a reason to reject an AXFR or IXFR, which would then lead to zone timeout and SERVFAIL unless corrected. that's not a problem. i was worried that this would be used in some way to permit/deny zone data to be used by a mixed-mode server in response to RD=1 queries. that would be a larger kettle of different fish. furthermore: Mark Andrews Thursday, November 27, 2014 2:45 PM Just having a cryptographically strong zone self consistancy check is a big win with IXFR. If that fails you AXFR the zone and try again. if you're trying to make a case for public key TSIG, i'd agree with you, and say, SIG(0) [RFC 2931]. i'd support an rfc 2931-bis effort, as a reviewer and as a contributor. For the root zone you don't need a iterative validator as you would have the root as a trust anchor and in general a authoritative server needs a interative resolver for NOTIFY. if you're arguing that NOTIFY should support DNSSEC by including RRSIG(SOA), i'd agree. but right now there is no TA on root zone slaves, they never query for anything, they never validate anything, they don't speak RFC 5011. and that's a deliberate design decision, not an accident or oversight. And the roots use TSIG to validate that they are talking to the server they think they are when performing a zone transfer. That doesn't preclude having the data added to the zone so others transfering from the root servers can verify that the contents are complete because validating all the validatable rrsets doesn't do the job. Whether is is TSIG or these records you are using a cryptographic hash + a key to ensure that all the glue is correct and you are trusting the generator of that hash and signer to be doing the correct thing. And the key is tied back to a trust anchor directly or indirectly. As to whether you iterate or not also depends on the trust anchors installed, whether the keys are RFC 5011 managed or similar. Having a managed trust anchor for every zone isn't a be deal. adding RFC 5011 support to a non-mixed-mode (authority only) server would be a very big deal. so, that's an area of strong disagreement if we discuss it further. and the whole trigger for this discussion was a mixed mode server with a local copy of the root zone. As for adding RFC 5011 support for the zones it serves, a authorative server has all the data it needs to do that as part of its normal roll of being a authoritative server. It's only a matter or reading what it is serving to others. vixie -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742
Re: [dns-operations] cool idea regarding root zone inviolability
Mark Andrews mailto:ma...@isc.org Thursday, November 27, 2014 7:22 PM if your master server sends you a final (matching) SOA not having stuffed its end of the tcp session with all the right records in between, or if your TCP is allowing end-to-end badness without its CRC32 detecting same at the tcp segment level, then you have bigger worries. Given named does sanity checks when apply ixfr deltas and they actually have been known to trigger, knowing that you have a complete zone after applying a ixfr would be a good thing. ... ... Whether is is TSIG or these records you are using a cryptographic hash + a key to ensure that all the glue is correct and you are trusting the generator of that hash and signer to be doing the correct thing. And the key is tied back to a trust anchor directly or indirectly. is there some reason why an updated sig(0) is not a solution to this? As to whether you iterate or not also depends on the trust anchors installed, whether the keys are RFC 5011 managed or similar. Having a managed trust anchor for every zone isn't a be deal. adding RFC 5011 support to a non-mixed-mode (authority only) server would be a very big deal. so, that's an area of strong disagreement if we discuss it further. and the whole trigger for this discussion was a mixed mode server with a local copy of the root zone. is there a specification for how mixed-mode servers will validate data they don't fetch? as in, you really are making a recommendation for zone-level validation that would then permit zone-local data to be used in forming responses to recursive queries in a mixed-mode server? i'd like to hear the details of that, because while DNSSEC talks about how to validate data you receive in queries, it does not talk about how to validate data you've received in zone transfers. i argue that it's not a trivial exercise, even if an updated sig(0) could be used to validate zone transfers. (i remember more than olafur claims to, concerning why we don't have zone-level signatures today. it's related to why glue is not signed and does not need to be signed, and it comes from security theory not dns theory.) As for adding RFC 5011 support for the zones it serves, a authorative server has all the data it needs to do that as part of its normal roll of being a authoritative server. It's only a matter or reading what it is serving to others. i don't think this is true. rfc 5011 assumes that you're starting with a known-good TA and that you'll use this to validate subsequent changes to that TA. those starting conditions are not in effect on any authoritative-only server i have administered. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] cool idea regarding root zone inviolability
at: http://www.diplomacy.edu/policybriefs we see: http://www.diplomacy.edu/sites/default/files/DiploFoundation%20Policy%20Brief%20No%204%20WEB.pdf which contains: Policy suggestions1 • The Internet root zone should be inviolable at any time, wherever it may be located. • No state should have the jurisdiction to prescribe, adjudicate, or enforce policy over the Internet root zone. • The Internet root zone may only be modified through existing procedures or new ones that might be introduced in September 2015. • The inviolability of the Internet root zone should be based on customary law that recognises the consistent practice of no unilateral interference by the US authorities in the content of the Internet root zone. ...and more. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
Thanks Paul, FWIW, I have been working on this for a while with the Diplo foundation, and I am happy to answer questions (and of course listen to concerns). Patrik On 27 nov 2014, at 05:26, Paul Vixie p...@redbarn.org wrote: at: http://www.diplomacy.edu/policybriefs we see: http://www.diplomacy.edu/sites/default/files/DiploFoundation%20Policy%20Brief%20No%204%20WEB.pdf which contains: Policy suggestions1 • The Internet root zone should be inviolable at any time, wherever it may be located. • No state should have the jurisdiction to prescribe, adjudicate, or enforce policy over the Internet root zone. • The Internet root zone may only be modified through existing procedures or new ones that might be introduced in September 2015. • The inviolability of the Internet root zone should be based on customary law that recognises the consistent practice of no unilateral interference by the US authorities in the content of the Internet root zone. ...and more. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
