[DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-11.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNSSEC Operational Practices, Version 2 Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename: draft-ietf-dnsop-rfc4641bis-11.txt Pages : 79 Date: 2012-04-13 This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-11.txt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-11.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI: This version adopts the review items from Alfred and Marc. Best regards, Matthijs On 04/13/2012 09:11 AM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNSSEC Operational Practices, Version 2 Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename: draft-ietf-dnsop-rfc4641bis-11.txt Pages : 79 Date : 2012-04-13 This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-11.txt ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPh9IjAAoJEA8yVCPsQCW5ahgH+wehFS/Y3JqQ/5Ii6cmtRtIA aOjO0n+aNG8C0vuyAe4876gm+GdyYeoN8ZEd+BG0O0oy4/djvm6GaExFMLoQoGgz 6h8zqnCA3Gj4KtVBONLMXbl40xWkQxWMPOG3rx3hzjLVxACsQhr2uNg3xczfDqhy oUpER1Cpq90876O+lvd/pqnwcnEzSoXaNz4nZT4Yr0sB6W19OLjVziN0yIAUgjpp +Zafkw4QQGlkh9PLG+8W/bYf2Y3FMtmxdS1ZrZP8SW3RiBVBM00x9rKDtnuHhfDo 8JRfUyfBPiA/Q7+uexah9ivb4K0SPuKfBMpZccQz53nTxAEEGG3/bp99TXkQZzQ= =viD7 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [as112-ops] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item (fwd)
Hello, Joe Abley wrote: I think that we need a better mechanism to avoid lame delegations to the AS112 servers, given their loosely-coordinated nature. I like the idea that came up in Québec (which I shall attribute to Warren Kumari since I've seen other people do that, although I was not in the room at the time) that the add/drop problem is a lot simpler if every AS112 node hosts the zone +1 $ORIGIN . @ SOA ... NS something NS sensible I think the AS112 root zone database could look something like this: $ORIGIN . $TTL 360 . IN SOA node-fqdn node-contact ( 2012041200 3600 900 604800 86400 ) . IN NS as112-tracker.dns-oarc.net. . IN NS blackhole-1.as112.net. . IN NS blackhole-2.as112.net. as112-tracker.dns-oarc.net. IN Asomething as112-tracker.dns-oarc.net. IN something blackhole-1.as112.net. IN Asomething blackhole-1.as112.net. IN something blackhole-2.as112.net. IN Asomething blackhole-2.as112.net. IN something hostname.as112.net. IN TXT organization, location hostname.as112.net. IN TXT See http://as112.net/ for more information. hostname.as112.net. IN LOC something Purpose of this tracker is to allow WfMS et al to know where all the nodes are. The node-fqdn is supposed to be a unicast (as opposed to anycast) address and it should also be configured as the notify-source. and answers authoritatively on the addresses corresponding to something and sensible, returning NXDOMAIN for everything in the entire namespace apart from . (for which they ought never receive queries anyway). This is ugly to some eyes, but it works for domainers and it ought to work for us too. Any zones that were subsequently delegated to something and sensible (e.g. as part of an IANA action) would be immediately supported with no need for changes on any of the nodes offering service for something and sensible. As in my example above, the empty fake root zone needs to still have at least hostname.as112.net as well... This document (as112-cull) attempts to do some of this work, but I don't see a reason to bite off small mouthfuls if we can expend a small amount of extra effort and eat the whole sandwich at once. Hear hear. -- Aleksi Suhonen ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
Mark Andrews, Thursday, April 12, 2012 11:43 PM: -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Thursday, April 12, 2012 11:43 PM To: Stephan Lagerholm Cc: Ralf Weber; Marc Lampo; Nicholas Weaver; dnsop@ietf.org; Livingood, Jason Subject: Re: [DNSOP] on Negative Trust Anchors In message dd056a31a84cfc4ab501bd56d1e14bbbd2e...@exchange.secure64.com, Steph an Lagerholm writes: Mark Andrews Thursday, April 12, 2012 6:10 PM: On 12.04.2012, at 14:21, Marc Lampo wrote: It holds an alternative possibility to overcome the problem - for operators of validating name servers - of failing domains because of DNSSEC. The alternative is to have a parent regularly (no frequency defined) check the coherence of DS information they have against DNSKEY information it finds published. If the parent detects security lameness (term used in RFC4641bis) its possible reaction could be to remove the DS information. =3D From my experience, active parenting is not a good practice. Specifically in this case, you are assuming that the parent knows the algorithms used for the DS record. He would have to in order to validate. That might not always hold true. Additionally, the record is not 'yours', it is just parked in your zone by the child. For the parent to Tamper with either the NS or DS is IMHO not a good practice. =20 There is a difference between Tamper and Hey, you stuffed up. You need to fix the delegation or we will remove it as it is causing operational problems and yes there *are* RFCs that permit this to happen. Being Insecure is not necessary better than being Bogus. Hey you got hacked, so we will remove the DS so that people can get to that bogus site I said remove the delegation. Get their attention as doing anything else doesn't work. I have yet to understand how your parent to child DNS probes works. Specifically, if you can explain to me how you are distinguishing between: A) The DS and the DNSKEY does not match because there is an operational error at the child And B) The DS and the DNSKEY does not match because somebody is doing a man in the middle on my probes. Going back to the original claim that alternative is to have a parent regularly check the coherence of DS information and that a possible reaction could be to remove the DS I'm not supportive of such active parenting idea. I find the idea of negative trust anchors useful for recursive resolvers given that the operator of such recursive resolver uses a secure out of band technology to make sure that there is an operational mistake. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
Stephan, An interesting approach : if a parent removes DS information for a child, if it finds the child to be in error, then, can an attacker make the check fail (in order to get the DS removed) ? At least one thing : Unlike the Dan Kaminsky flavour of cache poisoning attach, there is no way that attacker could trigger the verification of the parent, nor can the attacker know when the parent actually does the verificiation. The draw back of negative trust anchors seems that it must be implemented on the validating name server side -- not centrally like the DS record. (and what if, to overcome the not centrally managed observation, there is a demand for some blacklist of domains that should not be validated ?) Otherwise, active parenting and negative trust anchors are two approaches to cope with the same problem. And they are not mutually exclusive. Kind regards, Marc -Original Message- From: Stephan Lagerholm [mailto:stephan.lagerh...@secure64.com] Sent: 13 April 2012 04:21 PM To: Mark Andrews Cc: Ralf Weber; Marc Lampo; Nicholas Weaver; dnsop@ietf.org; Livingood, Jason Subject: RE: [DNSOP] on Negative Trust Anchors Mark Andrews, Thursday, April 12, 2012 11:43 PM: -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Thursday, April 12, 2012 11:43 PM To: Stephan Lagerholm Cc: Ralf Weber; Marc Lampo; Nicholas Weaver; dnsop@ietf.org; Livingood, Jason Subject: Re: [DNSOP] on Negative Trust Anchors In message dd056a31a84cfc4ab501bd56d1e14bbbd2e...@exchange.secure64.com, Steph an Lagerholm writes: Mark Andrews Thursday, April 12, 2012 6:10 PM: On 12.04.2012, at 14:21, Marc Lampo wrote: It holds an alternative possibility to overcome the problem - for operators of validating name servers - of failing domains because of DNSSEC. The alternative is to have a parent regularly (no frequency defined) check the coherence of DS information they have against DNSKEY information it finds published. If the parent detects security lameness (term used in RFC4641bis) its possible reaction could be to remove the DS information. =3D From my experience, active parenting is not a good practice. Specifically in this case, you are assuming that the parent knows the algorithms used for the DS record. He would have to in order to validate. That might not always hold true. Additionally, the record is not 'yours', it is just parked in your zone by the child. For the parent to Tamper with either the NS or DS is IMHO not a good practice. =20 There is a difference between Tamper and Hey, you stuffed up. You need to fix the delegation or we will remove it as it is causing operational problems and yes there *are* RFCs that permit this to happen. Being Insecure is not necessary better than being Bogus. Hey you got hacked, so we will remove the DS so that people can get to that bogus site I said remove the delegation. Get their attention as doing anything else doesn't work. I have yet to understand how your parent to child DNS probes works. Specifically, if you can explain to me how you are distinguishing between: A) The DS and the DNSKEY does not match because there is an operational error at the child And B) The DS and the DNSKEY does not match because somebody is doing a man in the middle on my probes. Going back to the original claim that alternative is to have a parent regularly check the coherence of DS information and that a possible reaction could be to remove the DS I'm not supportive of such active parenting idea. I find the idea of negative trust anchors useful for recursive resolvers given that the operator of such recursive resolver uses a secure out of band technology to make sure that there is an operational mistake. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
Responding to a message at random ... I skimmed the draft, and with respect to the authors this is a terrible idea. DNSSEC is pointless if it's not used as designed. Providing an easy way to bypass validation makes many things worse instead of better ... not the least of which is that if an attacker has actually compromised the authoritative name servers for the domain you've just made their job 100% easier (and thereby removed all the protection that DNSSEC is supposed to provide). Furthermore, the mechanism is not necessary, since if you somehow had knowledge that it was safe to use the data even if it doesn't validate you can temporarily set up a forward zone that points to a non-validating resolver. The mentality that we need to provide crutches and bandages to paper over the mistakes by DNS admins is exactly what has perpetuated the long history of bad habits and zomg I can't believe that something so badly configured ever actually worked that is one of the reasons DNSSEC rollouts are failing in the first place. Providing more crutches and bandages is not the answer. Doug -- If you're never wrong, you're not trying hard enough ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
Doug Barton do...@dougbarton.us wrote: Furthermore, the mechanism is not necessary, since if you somehow had knowledge that it was safe to use the data even if it doesn't validate you can temporarily set up a forward zone that points to a non-validating resolver. AFAIK that doesn't work in BIND. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Northwest Forties, Cromarty, Forth: Northerly or northeasterly 5 or 6, occasionally 7 at first. Moderate or rough. Showers, becoming wintry. Good, occasionally moderate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
the information economics of this draft are all wrong. with all possible respect for the comcast team who is actually validating signatures for 18 million subscribers and is therefore way ahead of the rest of the industry and is encountering the problems of pioneers... this is not supposed to be comcast's problem. if someone that comcast's customers want to reach, blows their dnssec out by using the wrong keys or using expired signatures or whatever, then the problem ownership should rest with whosoever blows their dnssec -- not with comcast. it's only because comcast is first that comcast has to watch out for the deleterious effects of OPM (other people's mistakes) on comcast's own customers. comcast can't afford the help desk call volume that would come from another wrong-key failure at the social security administration's domain. but that doesn't make it comcast's problem. it would remain the social security administration's problem. we need to move quickly to the point where lots of large eyeball-facing network operators are validating, such that any failure to properly maintain signatures and keys and DS records, is felt most severely by whomever's domain is thus rendered unreachable. if everyone interested in working on this draft would take the time to turn on validation, then we could avoid inverting the information economics here. people who can't manage their keys and signatures properly (and i include my own vanity zones in that, since i'm not yet converted to the bind 9.9 way of doing things) should either expect trouble or uplevel their game or stay out of the game. i'm opposed to negative trust anchors, both for their security implications if there were secure applications in existence, and for their information economics implications. paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
On Fri, Apr 13, 2012 at 05:43:42PM +, Paul Vixie wrote: i'm opposed to negative trust anchors, both for their security implications if there were secure applications in existence, and for their information economics implications. +1 -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
On 13 apr 2012, at 22:09, Evan Hunt wrote: On Fri, Apr 13, 2012 at 05:43:42PM +, Paul Vixie wrote: i'm opposed to negative trust anchors, both for their security implications if there were secure applications in existence, and for their information economics implications. +1 +1 Patrik ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
On Apr 13, 2012, at 1:24 PM, Patrik Fältström wrote: On 13 apr 2012, at 22:09, Evan Hunt wrote: On Fri, Apr 13, 2012 at 05:43:42PM +, Paul Vixie wrote: i'm opposed to negative trust anchors, both for their security implications if there were secure applications in existence, and for their information economics implications. +1 +1 -1 Simply put, I'm not a huge believer of recursive resolver (rather than client) validation. But if you are going to do it... There are a few cases where it is valuable [1], but for every 'validate is the right answer', there are hundreds of cases, like the NASA case, where the authority is just screwing up. And in those cases, the economics are that DNSSEC is creating a DOS, and it is the one who's validating that's at least partially responsible because it is both validating and deciding that its clients should suffer. This is especially true for ISPs. If you want any other ISP to validate DNSSEC, they need a mechanism like this so they don't suffer through the problems that Comcast has already experienced. Because practice has shown that it is the recursive resolver, not the authority, that gets blamed. Lurk on the Google Public DNS mailing list, and you realize that even without DNSSEC, the resolver operator faces the blame for brokenness. Thus, at least for DNSSEC, resolver operators need to be able to override validation easily and efficiently. [1] And these cases require 'listen until you can get something that validates': Just accept then validate gives the wrong answer in these cases. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
On 13 apr 2012, at 22:24, Patrik Fältström wrote: +1 In a private chat I am asked to explain my +1. Let me explain why. Today, before negative trust anchors, the responsibility for whether a the resolution that is basis for a connection establishment is with the zone owner. If the signature fails, it fails, resolution fails, and the connection can not be established. Now, if we have negative trust anchors that the validator is controlling, then I interpret it as if this choice of ability to resolve a name moves from the zone owner to the validator (or as in the case of X.509 certs to the client). What I am against is this *CHANGE* in who is responsible. Further, I think for .COM (and in the US) we are extremely unlucky that more or less only one large validator started validating, and then one zone owner made mistakes with their DNSSEC data. This made the press and community blame the one that did right, the validator, when in fact the one that validated and rejected some RRs did the right thing. In Sweden, where we also had such incidents we did not give up that easy. But, we succeeded because of a I think two things: - We managed to have more than one major ISP/Resolver to start validating on the same date, so as far as I know, no incident, regardless of how bad it was, was ever one that blamed the validator. - We managed to educate press and whoever that could help put a wet blanket over all rumors that the validator was the one to blame when validating did not work. Of course this was MUCH easier in Sweden that is a much smaller country than the group of entities that uses .COM. But, all of this thinking leads me to think about DNSSEC validation risks are very similar to the risk with deploying IPv6? We have an IPv6 day, but why not a DNSSEC day? One day where *many* players at the same time turn on DNSSEC validation? If we did, then maybe it would be easier for parties to turn on validation, because it could be easier for them to explain that it is not whoever that is validating that is making mistakes at failures, but instead the zone owner? And to go back to the +1, I say strongly +1 because alternatives (like what I just described) to changing who is responsible for making a decision of whether validation should work or not are not explored enough. Definitely not. I am not giving up yet, although after my work in a role being responsible for many products at an ISP 1996-2000 I definitely understand what the cost is with negative press and increased number of calls to customer service. Patrik ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
On 13 apr 2012, at 22:44, Nicholas Weaver wrote: Because practice has shown that it is the recursive resolver, not the authority, that gets blamed. As you saw in my mail, I completely disagree from my own personal experience. If I look at the number of failures, the number of cases where the validator is blamed is exactly one -- Comcast in the NASA case. Compared to the about 50 cases or so when the zone owner/signer is blamed. Yes, we have been running DNSSEC validation in Sweden a bit longer than in the USA. Can you please comment on that mail that uses a few more characters than '+1' please? Patrik ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
... More pragmatically, while I understand the theory behind rejecting NTAs, I have to admit it feels a bit like the IETF rejecting NATs and/or DNS redirection. I would be surprised if folks who implement NTAs will stop using them if they are not accepted by the IETF. Doing the validation on my machine makes it easy for me to realize who to blame when things break but I realize others don't have that insight or run validators, so I see the pain for the validating ISP. However, it is still not a reason for the IETF to standardize this. (paf) But, all of this thinking leads me to think about DNSSEC validation risks are very similar to the risk with deploying IPv6? We have an IPv6 day, but why not a DNSSEC day? One day where *many* players at the same time turn on DNSSEC validation? (drc) Definitely a good idea. It is seems a nice idea but a problem is that a single day is probably not enough. IPv6 problems are (nearly) instantaneous but with DNSSEC problems start to arise when things expire. jaap ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
On Apr 13, 2012, at 2:39 PM, Patrik Fältström wrote: http://kommunermeddnssec.se/maps.php This is one of the coolest thing i have clicked in long time.. thanks for sharing mehmet ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote: More pragmatically, while I understand the theory behind rejecting NTAs, I have to admit it feels a bit like the IETF rejecting NATs and/or DNS redirection. I would be surprised if folks who implement NTAs will stop using them if they are not accepted by the IETF. it is still not a reason for the IETF to standardize this. With the implication that multiple vendors go and implement the same thing in incompatible ways. I always get a headache when this sort of thing happens as the increased operational costs of non-interoperable implementations usually seems more damaging to me than violations of architectural purity. Different perspectives I guess. It is seems a nice idea but a problem is that a single day is probably not enough. IPv6 problems are (nearly) instantaneous but with DNSSEC problems start to arise when things expire. Crawl before running a marathon. If we get to a point where people actually deploy signing and/or validation systems, I'd call it success. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
