Re: [DNSOP] [dns-privacy] Qname minimization IPR
[Copy to dnsop since the qname minimisation draft is now a WG item at dnsop.] On Thu, Oct 23, 2014 at 10:21:57AM -0700, David Conrad d...@virtualized.org wrote a message of 56 lines which said: http://www.google.com/patents/EP266A1?cl=en Well, some resolvers (the programs which will have to implement qname m12n) are maintained in Europe (for instance Unbound) so they can safely ignore these patents http://en.wikipedia.org/wiki/Software_patents_under_the_European_Patent_Convention Back to IETF issues: can someone who have read RFC 3979 more thoroughly than me tell me if, as the draft author, I'm supposed to file the IPR disclosure or is it up to Verisign employees? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt
On 10/24/14, 6:06 PM, Doug Barton do...@dougbarton.us wrote: But worse yet, in the operator error case you make such errors painless. Instead, if they are painful (as in, screw up DNSSEC and you go off line) then it leads to more people taking DNSSEC seriously, and doing it right. Of course I realize that the counter-argument is that if DNSSEC fails are too painful then people will simply not do it. But to the extent that people use that as a line of reasoning it's simply one more in a long string of excuses. I think we¹re seeing a collision of how we¹d like the world to work and how it actually works. ;-) Operators are on the front lines here; trust us on the realities of getting stuff like this deployed. While I totally get 110% agree that when someone screws up their auth records they should feel the pain - and that this pain is a signal to do it better/right the next time - the reality is that the real pain is felt by the DNS operator. Of course I am going to pains to point out who is really to blame here: http://tools.ietf.org/html/draft-livingood-dnsop-auth-dnssec-mistakes-00 Anyway, if a popular domain like google.com or facebook.com or netflix.com was to sign - and then made a mistake - the call centers of an validating operator would pretty much melt down. It wouldn¹t matter that we were not to blame, we¹d feel the pain and people would be angry at us. There¹d be pressure to Œmake the pain stop¹ (and associated costs). Oh - and these days in the U.S. we¹d probably be blamed for ³blocking access² to the site - violating net neutrality (that the facts would say otherwise wouldn¹t matter**). So - two choices - turn off DNSSEC validation for ALL domains or just the one affected (assuming you can prove out it is a mistake and not an attack). Which one is worse? The market has already answered that: Negative Trust Anchors - turn it off in as narrow a case as possible. The question for us here is whether we wish to acknowledge this reality or pretend it does not exist. ;-) The other problem is that this feature is only really useful in the DNSSEC ramp-up period. Sure, mistakes are more common now, software is immature, etc. etc. But if DNSSEC is successful, the software will get better (it already is a lot better than even a few years ago), and mistakes will be less common (both on an absolute, and on a percentage basis). But once you introduce a feature like this, you cannot remove it. We address the timeframe issue in the draft. Certainly you are correct that the feature is still there afterwards, but of course the feature already exists today so the genie is out of the bottle as they say. So can we please let the functionality of DNSSEC stand as designed, and not give people a giant trapdoor that they can trigger at the slightest sign of trouble? Otherwise, why bother? I wouldn¹t say that it is at the Œslightest¹ sign of trouble. This is intended for use when there are major problems. Turning this around: DNSSEC deployment only got as far as it did to date because of NTAs. Without NTAs, I don¹t believe it¹ll go much further. So do we want to help the world understand what it takes to push ahead with DNSSEC? ... and of course, I should point out that adding this as a knob is utterly pointless, since any reasonably competent validating resolver operator can engineer their own trapdoor. Yes - we all decided the way to do it was with a Negative Trust Anchor. That¹s what the draft documents. ;-) - Jason Livingood ** From the discussion above (scroll back up to refresh your memory). A good recent example is a claim by some anonymous poster in a Reddit thread that Comcast was blocking Tor. Within hours it went viral and was posted to major news sites, never mind that it wasn¹t true. I posted http://corporate.comcast.com/comcast-voices/setting-the-record-straight-on- tor and yet still to this day there are tweets and reposts about how we block Tor, pointing back to the original news articles. I can¹t wait for what will happen when a major domain breaks if a NTA did not exist. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt
Doug, On Oct 24, 2014, at 3:06 PM, Doug Barton do...@dougbarton.us wrote: I know that there will be some philosophical objections / discussions on this... It's not just a philosophical objection, it's an operational one. When DNSSEC fails for a domain there are 2 main reasons. Operator error, and an actual MITM or similar attack. In these early days of DNSSEC deployment, we've seen numerous occasions in which the first has applied. Can you provide URLs to the cases where the second has applied? If the operators of validating resolvers simply turn off validation for domains that should be validating but are not,* it kicks the door open for the exact problem that DNSSEC was designed to solve. In the cases I'm aware of when an actual attack that DNSSEC was designed to solve has occurred, there are artifacts in logs. I would presume network operators would, when they get notified that a domain isn't validating, check those logs in their process to determine what's going on. If they notice the artifacts, I suspect they won't install an NTA. But worse yet, in the operator error case you make such errors painless. Only if you believe there will be universal and instantaneous deployment of NTAs any time the zone operator screws up. I suspect this unlikely. Of course I realize that the counter-argument is that if DNSSEC fails are too painful then people will simply not do it. But to the extent that people use that as a line of reasoning it's simply one more in a long string of excuses. No. It is an acceptance of the operational reality that, at least today, the most common failure mode (by far) is for zone operators to screw up and the remedy for that other person screwing up is to either tell the resolver operators' customers sorry, the guys at auth zone made a booboo and you can't talk to them as long as you use our resolver or turning validation off for ALL zones. If a zone is sufficiently popular that a resolver operator gets multiple calls when it doesn't validate because the zone's operated boobooed, the resolver operator _will_ turn off validation. Do that enough times and I suspect it becomes questionable whether they'll bother to turn it on again. The other problem is that this feature is only really useful in the DNSSEC ramp-up period. Sure, mistakes are more common now, software is immature, etc. etc. But if DNSSEC is successful, the software will get better (it already is a lot better than even a few years ago), and mistakes will be less common (both on an absolute, and on a percentage basis). But once you introduce a feature like this, you cannot remove it. You seem to believe that installing NTAs is without cost. First, it requires operator intervention in response to a notification. Second, I believe it opens the resolver operator up to liability -- by installing an NTA, they are, by direct intervention of their staff, purposefully defeating a protection that they explicitly configured that puts all of their customers at risk. The longer the NTA is left in place, the greater the risk. ... and of course, I should point out that adding this as a knob is utterly pointless, since any reasonably competent validating resolver operator can engineer their own trapdoor. Since not all validating resolvers support NTAs, if you want to supply text, I'd support adding a section describing alternative approaches to implementing NTA functionality. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] Qname minimization IPR
On Oct 25, 2014, at 5:24 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: Back to IETF issues: can someone who have read RFC 3979 more thoroughly than me tell me if, as the draft author, I'm supposed to file the IPR disclosure or is it up to Verisign employees? You should, not must, file a third-party disclosure; you could ask Danny McPherson to file one so you don't have to, but one way or another the IPR disclosure needs to happen so people don't step on a land mine. You are not obligated by the note well to do this--it's just the right thing to do, IMHO. Of course, now that we all know about it, anyone who's read this mail could in principle file the third-party disclosure. And also if anyone from Verisign is participating, they are required to disclose, because after this discussion they should be aware of the patent even if they weren't previously. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] Qname minimization IPR
On 25/10/14 15:56, Ted Lemon wrote: And also if anyone from Verisign is participating, they are required to disclose, Well, only if they think that the IPR is relevant. Their claims (I've not read 'em) could after all be unrelated to the draft, e.g. if they've only claimed some madly complicated way of getting the same effect as just leaving stuff out (which no doubt the USPTO might still, in their infinite wisdom, consider patentable;-). S. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On Mon, Oct 20, 2014 at 05:26:29PM -0400, Phillip Hallam-Baker hal...@gmail.com wrote a message of 74 lines which said: If we are going there, I would want to know how common the configurations are. Yes, actual numbers seen from a real resolver would be useful. Outside this list how common are hierarchies more than 4 levels deep in practice? ip6.arpa, and other infrastructure domains? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On Mon, Oct 20, 2014 at 05:03:19PM -0400, Bob Harold rharo...@umich.edu wrote a message of 135 lines which said: With minimization: Besides the fact that it is true only for a cold cache (as mentioned by others in this thread), it depends on how minimisation is implemented. One possible way is aggressive minimisation (the algorithm you describe), but another one is lazy minimisation (sending the full qname at the beginning and learning the zone cuts, then switching to minimisation). If it is realistic (I did not analyze the idea in detail), lazy minimisation will bring less privacy but will improve performances. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] Qname minimization IPR
The claims are broad, not specific to one field of use. But there isn't a patent yet and they may have been waiting to file after grant. It is possible for someone other than the IPR holder to file but best if its the IPR holder. The mere existence of a patent does not necessarily mean an intention to enforce. On Sat, Oct 25, 2014 at 11:51 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 25/10/14 15:56, Ted Lemon wrote: And also if anyone from Verisign is participating, they are required to disclose, Well, only if they think that the IPR is relevant. Their claims (I've not read 'em) could after all be unrelated to the draft, e.g. if they've only claimed some madly complicated way of getting the same effect as just leaving stuff out (which no doubt the USPTO might still, in their infinite wisdom, consider patentable;-). S. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On Tue, Oct 21, 2014 at 02:14:49PM +0900, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote a message of 27 lines which said: As the choice between privacy and latency is on resolver side, moderate latency is not harmful. I fully agree. Qname minimisation is an _unilateral_ decision. Any resolver can make its own trade-off, depending on its administrator's choices. dataminimisation: on|off (programmers, pick the best default value) Right, NXDOMAIN returned by some broken implementation to empty non-terminals MUST NOT be interpreted that the terminals does not exist. Full agreement again and I suggest everyone to consider draft-vixie-dnsext-resimprove-00, section 3 (an useful thing for qname minimisation but also against current random qnames attacks https://indico.dns-oarc.net//contributionDisplay.py?contribId=37sessionId=3confId=20). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] Qname minimization IPR
On Oct 25, 2014, at 2:03 PM, Phillip Hallam-Baker ph...@hallambaker.com wrote: The claims are broad, not specific to one field of use. But there isn't a patent yet and they may have been waiting to file after grant. It is possible for someone other than the IPR holder to file but best if its the IPR holder. The mere existence of a patent does not necessarily mean an intention to enforce. Verisign has been telling its investors that they have intention to enforce and monetize patents. Excerpts from their SEC filings and investor calls can be found at: http://domainnamewire.com/2013/01/25/heads-up-competing-registries-verisign-might-start-asserting-its-patents/ http://domainnamewire.com/2013/01/25/heads-up-competing-registries-verisign-might-start-asserting-its-patents/ http://domainnamewire.com/2014/09/24/verisigns-standards-group-patents/ http://domainnamewire.com/2014/09/24/verisigns-standards-group-patents/ Rubens ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] Qname minimization IPR
Stephane Bortzmeyer mailto:bortzme...@nic.fr Saturday, October 25, 2014 2:24 AM [Copy to dnsop since the qname minimisation draft is now a WG item at dnsop.] On Thu, Oct 23, 2014 at 10:21:57AM -0700, David Conrad d...@virtualized.org wrote http://www.google.com/patents/EP266A1?cl=en importantly, google's policy is to use patents only in defense. i've requested that they make that explicit in the case of this particular patent, but, that's a small detail. i believe that query minimization should proceed as though this patent did not exist, for the good of the internet economy. (if it fails to reach consensus that's a different matter, but, let it not be because of this patent.) -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] Qname minimization IPR
Paul, It is a VeriSign patent, its just being shown on the Google patent serach engine On Sat, Oct 25, 2014 at 1:53 PM, Paul Vixie p...@redbarn.org wrote: Stephane Bortzmeyer bortzme...@nic.fr Saturday, October 25, 2014 2:24 AM [Copy to dnsop since the qname minimisation draft is now a WG item at dnsop.] On Thu, Oct 23, 2014 at 10:21:57AM -0700, David Conrad d...@virtualized.org d...@virtualized.org wrote http://www.google.com/patents/EP266A1?cl=en importantly, google's policy is to use patents only in defense. i've requested that they make that explicit in the case of this particular patent, but, that's a small detail. i believe that query minimization should proceed as though this patent did not exist, for the good of the internet economy. (if it fails to reach consensus that's a different matter, but, let it not be because of this patent.) -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] Qname minimization IPR
On Oct 25, 2014, at 10:53 AM, Paul Vixie p...@redbarn.org wrote: http://www.google.com/patents/EP266A1?cl=en http://www.google.com/patents/EP266A1?cl=en importantly, google's policy is to use patents only in defense. i've requested that they make that explicit in the case of this particular patent, but, that's a small detail. 1) It is a patent application, not a patent. 2) The application was filed by Verisign, not Google. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Stephane Bortzmeyer mailto:bortzme...@nic.fr Saturday, October 25, 2014 9:05 AM On Tue, Oct 21, 2014 at 02:14:49PM +0900, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote a message of 27 lines which said: Right, NXDOMAIN returned by some broken implementation to empty non-terminals MUST NOT be interpreted that the terminals does not exist. i disagree with this. broken implementations who emit NXDOMAIN for empty non-terminals cannot be used as an excuse not to develop and deploy correct protocol and software enhancements. the internet has hundreds of years to run yet, and these broken implementations are (a) shrinking not growing, and (b) subject to rapid replacement when they start to encounter problems with correct enhancements to their habitat. Full agreement again and I suggest everyone to consider draft-vixie-dnsext-resimprove-00, section 3 (an useful thing for qname minimisation but also against current random qnames attacks https://indico.dns-oarc.net//contributionDisplay.py?contribId=37sessionId=3confId=20). stephane, i believe you misunderstood the sense of ohta-san's remarks. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] Qname minimization IPR
Paul Hoffman mailto:paul.hoff...@vpnc.org Saturday, October 25, 2014 11:06 AM 1) It is a patent application, not a patent. 2) The application was filed by Verisign, not Google. --Paul Hoffman thanks. however, i was told google also has one on Q-M. that's the one i thought this thread referred to. if verisign tries to enforce their patent against google, i will buy popcorn, sit back, and watch. i do not believe that verisign's interests are aligned with enforcement of a patent like this one. verisign should be asked to place a defense-only status on this patent. i think they will do so. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
On Sat, Oct 25, 2014 at 06:05:16PM +0200, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 24 lines which said: Right, NXDOMAIN returned by some broken implementation to empty non-terminals MUST NOT be interpreted that the terminals does not exist. Full agreement again Paul Vixie was right, I've read your sentence too fast. I focused on the broken implementation part (on which we agree, these implementations are awfully broken) and missed the meaning of the double negation. So, to rephrase it, my opinion is: NXDOMAIN returned by some broken implementation to empty non-terminals is a bug. A NXDOMAIN MUST be interpreted as the node in the domain tree, AND ALL ITS SUBNODES, do not exist. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt
On Sat, Oct 25, 2014 at 3:30 PM, Paul Ebersman list-dn...@dragon.net wrote: dougb It's not just a philosophical objection, it's an operational dougb one. When DNSSEC fails for a domain there are 2 main dougb reasons. Operator error, and an actual MITM or similar attack. If dougb the operators of validating resolvers simply turn off validation dougb for domains that should be validating but are not,* it kicks the dougb door open for the exact problem that DNSSEC was designed to dougb solve. Have you actually read through the new draft? It specifically prohibits automatic installation of NTAs and says that you should have folks familiar with operating DNS servers making any decisions. That isn't painless. It means that this skips past all 1st tier and gets to senior engineers. Don't know about you but I hate getting on-call problems caused by someone else that I have no direct way to fix but that my customers beat me for. ... or that your customers move away because of... http://forums.comcast.com/t5/Basic-Internet-Connectivity-And/Re-Weather-Gov-DNS/td-p/1175625 http://www.dslreports.com/forum/remark,25180845?hilite=dns http://forums.comcast.com/t5/Basic-Internet-Connectivity-And/Comcast-DNS-can-t-won-t-find-state-gov-sites-How-do-I-report/td-p/1824503 And that's way more expensive than standard help desk... But it is a good way to make sure that this isn't a constant and knee jerk reaction but an operationally sane one. dougb The other problem is that this feature is only really useful in dougb the DNSSEC ramp-up period. Sure, mistakes are more common now, dougb software is immature, etc. etc. But if DNSSEC is successful, the dougb software will get better (it already is a lot better than even a dougb few years ago), and mistakes will be less common (both on an dougb absolute, and on a percentage basis). But once you introduce a dougb feature like this, you cannot remove it. ... but you don't have to remove it. If DNSSEC is successful, the software will get better (it already is a lot better than even a few years ago), and mistakes will be less common then there will be no need to install NTAs. Sure. It will only be temporary/fast. Like rolling out IPv6. Or getting all the broken CPEs using old dnsmasq and being open resolvers. Or getting folks to roll out BCP38. How long have we been trying to get folks to use DNSSEC? ... a long time... How far are we? not far enough... And why do we keep insisting that only by painful and expensive suffering will we do it correctly? Not a clue. This is like saying that airbags and selt-belts are a bad idea in cars -- if we didn't have them, people would learn to drive more carefully[0]. This is potentially true, but... seriously... W [0]: This inserted somewhat so that I can trot out my current favorite quote: Analogies are like bicycles: It doesn’t matter how many marbles it takes to fill the outhouse, telco execs will always be making silly metaphors — Patrik Gilmore. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
