Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record
To begin...thanks, Frederico, I was trying to find that case but had forgotten which ccTLD was involved. (Web searches failed me...) On 11/14/17, 23:11, "DNSOP on behalf of Paul Wouters" wrote: >On Wed, 15 Nov 2017, Frederico A C Neves wrote: > >> Yes. And add to that cases were TLDs rolled just before adding to the >> root. > >So what is the security model then? Keep in mind that DNSSEC is enabling the receiver to validate the DNS protocol was followed. (Including, if the DNS has bad data in it, the bad data is protected.) >Let's say .example rolled and now has a bad DS. This has happened a number of times already. >Someone overrides this with a local trust anchor so the domain does not go >dark. Or configures a negative trust anchor. >- How do you know the roll was legitimate? In-band, you can't tell. But word of mouth speeds quickly, for better or worse. One quip from one case was "twitter is faster than nagios!" (I don't know how a DNS message receiver would realize/detect a roll, outside of STD 69's automated updates process.) >- How does an application make a security decision about a found TLSA record >that depends on this trust anchor? That is a matter for the application, not the DNS. ... >Now same as above, but one of these rolls were done by an attacker and is >malicious. I am scratching my head a bit trying to first imagine a validator even detecting a key rollover, legit or not. As it is now, caches are fickle, if what's cached doesn't have the key needed, they SERVFAIL the answer, not get a new copy of the keys (because of rollover-and-die, an issue documented many years ago). They don't distinguish between a botched rollover and someone one-time forging a response. >Trusting "any"thing is just a path to madness. Not trusting anything is a path to paranoia. ;) Madness or paranoia... The case for "any" trusted chain is rooted in the desire to retain as much robustness when slapping on security. This assumes that the greater issue lies in operational errors than re-delegation of zones. The track record shows that operator error is the greater source of DNSSEC invalidations, on the other hand, the thought that data gets misdirected is a concern. Ask this question...when a validator begins to systematically SERVFAIL data, what happens now? Followed actions include checking DNSVIZ to see if there's a DNSSEC problem with the authority and potentially negative trust anchors being applied. (This in the response to trouble tickets being lodged, support desk calls, etc.) With this as the current response, would preferring trust anchors over DS records (to put this problem tritely) be effective? Once a validator notes a re-delegation, the operator might just open the flood gates and let all the traffic go to the re-delegation anyway. (Not, myself, understanding if the operator, when adding a negative trust anchor would realize there was a positive trust anchor for the same name.) smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record
On Wed, 15 Nov 2017, Frederico A C Neves wrote: Yes. And add to that cases were TLDs rolled just before adding to the root. So what is the security model then? Let's say .example rolled and now has a bad DS. Someone overrides this with a local trust anchor so the domain does not go dark. - How do you know the roll was legitimate? - How does an application make a security decision about a found TLSA record that depends on this trust anchor? Now .example rolls to yet another key to fix their mistake and updates the DS. - How does the application know the roll is legitimate? - How does an application make a security decision about a found TLSA record that depends on this trust anchor? - Who, why and when does the local trust anchor get deleted. What if _this_ is the key that example.com lost the private key to? Now same as above, but one of these rolls were done by an attacker and is malicious. Trusting "any"thing is just a path to madness. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record
On Mon, Nov 13, 2017 at 03:45:30PM +, Edward Lewis wrote: > On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt" behalf of e...@isc.org> wrote: > > >On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote: > >> Nice write-up Edward! You have nicely summarized why Mark and me agree > >> that validator should use longest suffix match when selecting TA to > >> validate data. > > > >+1. > > Hmmm, that wasn't my intent. ;) I had been trying to justify the other > conclusion. But, if my work is leading you towards this "other" conclusion, > I've been taking time to understand why. > > I'm beginning to have a new understanding on this. The overlooked (by me) > point is that we are focusing on a situation where the local operator has > chosen to explicitly configure a trust anchor. Beside code distributions > shipping with the IANA managed KSK (or its DS form) for the global public > Internet's root zone, if any operator wants another trust anchor point, they > have to take explicit action to configure it. The question is - what is the > expectation of the operator in doing this? > > There was a time when TLDs were signed but the root zone was not. Then > operators had to configure trust anchors for the TLDs to enable validation. > When the root zone was signed in 2010, the TLDs had to remind all those with > trust anchors to remove them (before the TLD could change it's KSK). I can > no longer find reports of the efforts to undo TLD trust anchors (Sweden and > maybe CzechRep?) that I thought were once floating around. "Fears" > surrounding this would lead one to favor the more open "any" policies, on the > other hand, mass migration from TLDs to root for the top of the trust chain > was probably a one-time event as a result of the on-set of DNSSEC in the root > zone. > Yes. And add to that cases were TLDs rolled just before adding to the root. https://eng.registro.br/pipermail/gter/2010-May/027981.html https://eng.registro.br/pipermail/gter/2010-June/028053.html https://eng.registro.br/pipermail/gter/2010-July/028138.html Fred ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record
On 11/13/17, 21:15, "DNSOP on behalf of Paul Wouters" wrote: >> I'm not sure that the need for robustness outweighs the expectation of >> someone explicitly adding a trust anchor anymore. >But that’s not your call to make, but the call of the entity deciding to put >in that hard-coded trust anchor. To clarify, the "robustness" was the goal of the protocol design leading up to the 2004 publication of the current DNSSEC definition, it's not a call anyone is making now. The goals of robustness, local policy, and other factors fed into the current design. How these, sometimes conflicting, objectives were weighted was subjective and with more 20/20 hindsight, perhaps the weightings were wrong. >We just ask you not to block us from doing as we have been doing for years. I don't know how to take this - what's being discussed is the way the protocol was designed in the past versus how implementations have chosen to go. In the spirit of code trumps spec, then specifications need to catch up if there's a deviation. >I would like split-DNS to die too but I dont think that’s happening soon. Arguing split-DNS would be another thread, I want to clarify that the "too" in your quote shouldn't implicate anything I've said about split-DNS meaning I wished it to "go away". (I.e., I see split-DNS as a reality.) smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record
On Mon, 13 Nov 2017, Paul Vixie wrote: whether DNS can adapt remains to be seen. but declaring working and desired configurations such as split-DNS to be undesireable, or breaking them, or failing to support them, are head-in-sand moves. the internet historically responds to head-in-sand moves by moving on in its own way. For the record, while I don't like split-dns, I do actively support it, even with DNSSEC, for instance in: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record
Paul Wouters wrote: I'm not sure that the need for robustness outweighs the expectation of someone explicitly adding a trust anchor anymore. But that’s not your call to make, but the call of the entity deciding to put in that hard coded trust anchor. We just ask you not to block us from doing as we have been doing for years. +1. all policy is local. OTOH, in the sense "I am not sure" there's the example of split-DNS and poor query path management (i.e., leaks). I'm not sure if robustness helps here, or is a bad-behavior enabler. I would like split-DNS to die too but I dont think that’s happening soon. -1. like NAT, we will have a better internet if we embrace split-DNS rather than wishing it wasn't real or wishing it did not exist. due to network partitions, both permanent and ephemeral, the global or universal namespace should be a last resort, after permitting namespace searches at the host, server, LAN, campus, corporate, league, and regional layers. names at any layer of this hierarchy should be treated as first-class, should be secure, and should be tagged so as to be either re-qualified when carried to higher or lower layers, or marked as unresolvable by those layers. whether DNS can adapt remains to be seen. but declaring working and desired configurations such as split-DNS to be undesireable, or breaking them, or failing to support them, are head-in-sand moves. the internet historically responds to head-in-sand moves by moving on in its own way. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record
> > I'm not sure that the need for robustness outweighs the expectation of > someone explicitly adding a trust anchor anymore. But that’s not your call to make, but the call of the entity deciding to put in that hard coded trust anchor. We just ask you not to block us from doing as we have been doing for years. > OTOH, in the sense "I am not sure" there's the example of split-DNS and poor > query path management (i.e., leaks). I'm not sure if robustness helps here, > or is a bad-behavior enabler. I would like split-DNS to die too but I dont think that’s happening soon. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record
On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt" wrote: >On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote: >> Nice write-up Edward! You have nicely summarized why Mark and me agree >> that validator should use longest suffix match when selecting TA to >> validate data. > >+1. Hmmm, that wasn't my intent. ;) I had been trying to justify the other conclusion. But, if my work is leading you towards this "other" conclusion, I've been taking time to understand why. I'm beginning to have a new understanding on this. The overlooked (by me) point is that we are focusing on a situation where the local operator has chosen to explicitly configure a trust anchor. Beside code distributions shipping with the IANA managed KSK (or its DS form) for the global public Internet's root zone, if any operator wants another trust anchor point, they have to take explicit action to configure it. The question is - what is the expectation of the operator in doing this? There was a time when TLDs were signed but the root zone was not. Then operators had to configure trust anchors for the TLDs to enable validation. When the root zone was signed in 2010, the TLDs had to remind all those with trust anchors to remove them (before the TLD could change it's KSK). I can no longer find reports of the efforts to undo TLD trust anchors (Sweden and maybe CzechRep?) that I thought were once floating around. "Fears" surrounding this would lead one to favor the more open "any" policies, on the other hand, mass migration from TLDs to root for the top of the trust chain was probably a one-time event as a result of the on-set of DNSSEC in the root zone. I'm not sure that the need for robustness outweighs the expectation of someone explicitly adding a trust anchor anymore. OTOH, in the sense "I am not sure" there's the example of split-DNS and poor query path management (i.e., leaks). I'm not sure if robustness helps here, or is a bad-behavior enabler. >> Things might get even more complicated when negative trust anchors are >> configured, bleh. > >Fortuantely a negative trust anchor is a longest suffix match too. This is an emerging "thing" - more active awareness and management of the trust anchor element of a validator. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
