Re: [dns-operations] 10% was Re: .mm ....
On Jan 21, 2013, at 5:26 AM, Jaroslav Benkovský jaroslav.benkov...@nic.cz wrote: On 01/19/2013 09:28 PM, Matthäus Wander wrote: I think it's more like I'll tolerate an expired signature for 10% of the original validity period and use that extra time to let other people notice and fix it. Assuming that 1) the majority of validators do *not* tolerate expired signatures and 2) most DNSSEC failures are fixed within that 10%, it is a way to trade off reliability vs. security. That's rather reminiscent of parents who don't get their children vaccinated for fear of side-effects and instead rely on *other* children being vaccinated. Being tolerant to garbled input is what caused the sorry mess of HTML, with its quirk parsing modes and incompatibilities. Hmmm… So, the issue is folk not resigning before the expiration. Some resolvers are loose -- they stretch the expirations. Other, more strict implementations mark the domain as bad when it expires -- this causes fallout / press / messages on dns-ops, and the domain admin notices and resigns. This makes the loose implementations look better -- folk running the loose implementations avoided having thier customers get grumpy, saved the cost of support calls, etc. So, basically the loose implementations are relying on the strict implementations to signal the domain admin (out of band) to resign. This negatively affects the reputation of the strict implementations and, eventually, we may run into an issue where the loose implementations all increase the slop factor to look better than their competitors… So, basically what is needed is a strong, out of band signal to the operators to resign… It seems that the only reliable way to do this is for the domain to go dark for some (non-insignificant) portion of users -- this triggers Where the hell did my traffic go? questions from the web server operators, news articles and eventually the pointy-haired boss types waking down the stairs and shouting…. So, obviously what is needed is a way to trigger these sorts of responses, but without creating as much of an incentive for loose implementations and slop factors… So, here is my proposal: 1: Everyone does strict implementations. 2: When the signature expires everyone does the following: A: You calculate by how much the zone has expired, normalize it, then multiply by 255 and call this EXPIRED-AMNT. B: You take the primary IP of your recursive server, hash it, take the last octet of the hash and call it REF-HASH. C: You hash the label of the zone apex, take the last octet and call it ZA-HASH. Now, if REF-HASH - ZA-HASH EXPIRED-AMNT you can still answer the query. This means that initially only 1/255 resolvers will view the zone as bogus, but as time goes by (up to double the validity interval) more and more resolvers will mark it bad. This allows for increasingly strong signals to the operator, but doesn't favor any one implementation…. You're welcome… W (Mumbles something about job security, then runs off, giggling madly…) It's not cool to be one of the few resolvers suffering from DNSSEC configuration errors that other people caused, while all the non-validating resolvers seem to work fine. The security benefit is hardly noticed by users outside of the DNS community as long as applications are not showing green DNSSEC icons or other gizmos. I used to work for the first major ISP here that switched DNSSEC validation on, so I can only commiserate with you :). Jarda Benkovsky ___ 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 -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. -- J.R.R. Tolkien ___ 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] 10% was Re: .mm ....
* Joe Abley [2013-01-19 03:31]: I'll assume (since I didn't see the original mail) that the proposal is to make validators tolerant by 10%, rather than to change anything on the authority server or on the signers. (If you want to extend the validity of a signature by 10% when you sign the zone you can already do that just by changing the parameters used by your signer.) If the idea is I'll tolerate an expired signature for 10% of the original validity period (I didn't see the original mail) then you're just trading a failure today for a failure today + T. I don't think there's much practical difference between those outcomes. I don't see the point of the change. If the idea is I'll tolerate an expired signature for 10% of the original validity period and use that extra time to shout loudly about the fact that there is a failure then I'd suggest just setting your monitoring systems to start the loud klaxons when you only have 10% validity remaining, and avoid the change too. I think it's more like I'll tolerate an expired signature for 10% of the original validity period and use that extra time to let other people notice and fix it. Assuming that 1) the majority of validators do *not* tolerate expired signatures and 2) most DNSSEC failures are fixed within that 10%, it is a way to trade off reliability vs. security. In this specific case it didn't really work out: $ dig dnskey mm @unbound.odvr.dns-oarc.net [...] ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 11736 [...] I don't see much good, here. I think the main things that are missing from the world are: - a pragmatic approach to setting signature validity periods in signers, mindful of operational considerations - people monitoring their own zones and getting early warnings when signer policy appears not to be reflected in the DNS Sure. But keep in mind that's not under control of the resolver operators. It's not cool to be one of the few resolvers suffering from DNSSEC configuration errors that other people caused, while all the non-validating resolvers seem to work fine. The security benefit is hardly noticed by users outside of the DNS community as long as applications are not showing green DNSSEC icons or other gizmos. Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Cryptographic 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
[dns-operations] 10% was Re: .mm ....
It's an acceptable idea - certainly not a bad one. Adding security to an existing system will, inherently, make it more brittle. What ever can be done to soften the brittleness while retaining the basic need for security should be done for the sake of resilience and availability of the system being secured. (Security should never be the objective, it's a supporting actor in achieving a higher objective.) The posed question is whether expanding the lifetime of a signature by 10% is a good idea. All that can be objectively stated is that no cache poisoning enabled by this ploy has ever been detected. That's why I said it is acceptable and not bad, I didn't say it was a good idea in the sense we will never know. Data sets that validly fall into this 10% region may fall in to this state for reasons other than operator sloppiness, so the assertion that this encourages more sloppiness is not necessarily true. What it might do (in the sense I have no data to tell) is reduce support call volume, which is a significant benefit. From reading lists, talking to folks and watching operations, I have learned of more failed validations caused by hardware failures, disaster recovery mishaps and operational mistakes than other reasons, including operator sloppiness and malicious activity. So trimming failed validations by removing brittleness is a good place to start. I'll define sloppiness as failure to refresh signatures in time (or not automate that). There are a lot of other things that can go wrong despite attentive care, including clocks drifting, external events overrunning planned capacity, and so on. On Jan 18, 2013, at 10:06, Chris Thompson wrote: Is fudging the expiry times like that really a good idea? If all all validators allowed a 10% overrun, DNS operators would just get 10% sloppier and we would back where we started. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ 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] 10% was Re: .mm ....
On Jan 18, 2013, at 11:05 AM, Edward Lewis wrote: Adding security to an existing system will, inherently, make it more brittle. I strongly disagree with this statement. Increasing resilience under duress should be a key goal of any security enhancement; if it doesn't do this, then it hasn't been designed/implemented properly. So trimming failed validations by removing brittleness is a good place to start. I agree with this statement, and most everything else you say, 100%. Perhaps 'adding security' wasn't really what you meant in the first sentence? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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] 10% was Re: .mm ....
On Jan 18, 2013, at 12:18, Dobbins, Roland wrote: On Jan 18, 2013, at 11:05 AM, Edward Lewis wrote: Adding security to an existing system will, inherently, make it more brittle. I strongly disagree with this statement. Increasing resilience under duress should be a key goal of any security enhancement; if it doesn't do this, then it hasn't been designed/implemented properly. (Perhaps the second half of the message should be first...meaning I think the issue is in what I meant by adding.) This was the proof offered to me (about the impact of bolting-on/retrofitting - as I meant adding) years back: Take an existing (vulnerable) system and model it as a state machine. States can be classified as safe, perilous, and unsafe. Perilous states are those which are safe but have an arc into an unsafe state. The act of adding security on to the system has the effect or preventing the system from entering unsafe states and perilous states, in the effort to prevent falling into unsafe states. What is lost then, is any transition from a safe to perilous to safe states which per se is not a problem but is no longer permitted. This is the brittleness I refer to. Looking back on this proof - I suppose if there were no safe-perilous-safe state transitions, there's no increase in brittleness. KInd of a degenerate case in the proof. So trimming failed validations by removing brittleness is a good place to start. I agree with this statement, and most everything else you say, 100%. Perhaps 'adding security' wasn't really what you meant in the first sentence? Adding security maybe the trip up. Maybe I should have used the term I normally use bolted-on security. When I wrote adding I had in mind the kind of addition like DNSSEC on DNS - which is a case of bolted-on security. It was a discussion over that where I was given the above proof. Adding security as an ingredient in the initial architecting of a solution won't make the system more brittle. (Well, if the solution is new - it can't be more anything. ;) ) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ 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] 10% was Re: .mm ....
On 2013-01-19, at 06:05, Edward Lewis ed.le...@neustar.biz wrote: The posed question is whether expanding the lifetime of a signature by 10% is a good idea. I'll assume (since I didn't see the original mail) that the proposal is to make validators tolerant by 10%, rather than to change anything on the authority server or on the signers. (If you want to extend the validity of a signature by 10% when you sign the zone you can already do that just by changing the parameters used by your signer.) If the idea is I'll tolerate an expired signature for 10% of the original validity period (I didn't see the original mail) then you're just trading a failure today for a failure today + T. I don't think there's much practical difference between those outcomes. I don't see the point of the change. If the idea is I'll tolerate an expired signature for 10% of the original validity period and use that extra time to shout loudly about the fact that there is a failure then I'd suggest just setting your monitoring systems to start the loud klaxons when you only have 10% validity remaining, and avoid the change too. I don't see much good, here. I think the main things that are missing from the world are: - a pragmatic approach to setting signature validity periods in signers, mindful of operational considerations - people monitoring their own zones and getting early warnings when signer policy appears not to be reflected in the DNS If you plan to refresh your signatures every 7 days, you know that sometimes there are failures which might take 4 days to mitigate (long weekends, etc) and you know that the number 4 in the preceding phrase is a bit woolly, then make your signature validity 7 + 3 * 4 = 19 days. If 3 is not a good enough woolly factor, make it higher. If 4 is not enough days, make it higher. If you see signatures persist beyond 7 days, sound the alarm, but know that you don't have to panic because you have another (e.g.) 12 days before any embarrassing impact of human waste vs. rotating blades. The numbers here all depend on local circumstances. I can't imagine a 10% style number that would have universal application. If these kinds of things are too hard to think about, don't deploy DNSSEC. Joe ___ 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
