> 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 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

Reply via email to