> On 4 Feb 2018, at 2:31 pm, Lanlan Pan <abby...@gmail.com> wrote: > > > > Mark Andrews <ma...@isc.org>于2018年2月3日周六 上午4:11写道： > The problem is that search lists are being applied when “localhost” is being > entered into name lookup APIs and is being matched against localhost.example > which isn’t expected to to a address on the current machine and that the > search list may be auto constructed or come from a untrusted source. > > If only consider about http: http://seclists.org/bugtraq/2008/Jan/270 > Web browser can also ban this "localhost.example". > CA Single Sign-On might help to solve the "same site" cookie expose problem.
We may as well ban www.example because that can return 127.0.0.1 as well. :-) The first step to fixing this is to record the address that cookies are learnt from and not allow them to be sent to address with a different scope. This would address this issue as www.paypal.com has a different address scope to localhost.paypal.com. This however isn’t something for dnsop. > There is also a small risk that hotspots will return something other than a > local address if a address lookup for .localhost is made. > > This is all in the context of processing urls. > > Localhost is the last remanent of the pre hierarchical host scheme. > > The risks are eliminated if the name APIs use local lookup sources in those > contexts. > > Then you have legacy clients. As long as the servers for the namespace on the > public Internet don’t return A or AAAA records for localhost the issue is > addressed there. > > You then have the recursive server where you would like it, by default, > return a answer without contacting the root servers. The only safe way to do > that is to have it serve a empty zone for localhost. As this zone isn’t > linked into the global DNSSEC chain of trust the root zone needed a insecure > delegation for localhost. > > > > -- > Mark Andrews > > On 3 Feb 2018, at 05:25, Bob Harold <rharo...@umich.edu> wrote: > >> >> On Thu, Feb 1, 2018 at 4:26 PM, Ted Lemon <mel...@fugue.com> wrote: >> On Feb 1, 2018, at 2:48 PM, Andrew Sullivan <a...@anvilwalrusden.com> wrote: >>>> As a general principle, when what the RFC says to do is not the right >>>> thing to do, the solution is to update the RFC, not to ignore the problem. >>> >>> I strongly agree with this (as I think or anyway hope you know) >> >> Yes, I will admit I was a bit surprised that you put it that way, although >> as you say, your position is more clear in your formal review of the >> document. >> >> As for why I responded to this and not to the formal review, the answer is >> that the formal review was a bit overwhelming. You made a lot of assertions >> of fact that didn't sound like fact to me—they sounded like strongly-held >> opinion. You are a much more experienced DNS expert than I am, so for me >> to argue you away from those opinions is a tall order—I don't think you've >> really expressed the underlying belief that is the keystone to the whole >> edifice. >> >> The problem I have is that to me it's dead obvious that the name hierarchy >> and the set of names in the DNS are not the same thing. We've had that >> discussion before. We even published a document about it, which hasn't >> quite made its way out of the RFC editor queue yet. It seems to me that it >> is demonstrably the case that these two sets are disjoint. >> >> But you explain your reasoning on the basis that clearly they are the same >> set, and that they are the same set is left unexamined. So if we were to >> succeed in understanding why we disagree on this point, it would be >> necessary to dig down into that. >> >> Having seen you give keynotes at the plenary, I know that you are deeply >> concerned about computer security. The reason that I am in favor of the >> behavior I'm propounding is that I think it closes a small security gap >> through which a truck might some day be driven, to our woe. So to me, the >> need to leave that gap, which I admit is small, open, seems inconsistent >> with what I know of you. >> >> So clearly you value this idea that localhost is a name that exists in the >> DNS, even though it doesn't exist in the DNS. It might be fruitful to >> explore that further. It might also be a waste of time. I don't honestly >> know. But that is, I think, the key to our disagreement. >> >> >> Could someone explain the security problem? If it really is bigger than the >> problems that will be caused by changing resolvers to answer with NXDOMAIN, >> then you might convince me. >> >> -- >> Bob Harold >> >> _______________________________________________ >> 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 > -- > 致礼 Best Regards > > 潘蓝兰 Pan Lanlan -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
