The Two Lookups Approach (was Re: Parsing the issues and finding a middle ground -- another attempt)

Vint Cerf vint at google.com
Fri Mar 6 15:07:50 CET 2009


While I haven't analyzed things as carefully as Marcos attempts in his  
note, I have to admit to a lot of discomfort with having to do two  
lookups to get this stuff to work.

v


Vint Cerf
Google
1818 Library Street, Suite 400
Reston, VA 20190
202-370-5637
vint at google.com




On Mar 6, 2009, at 9:03 AM, Marcos Sanz/Denic wrote:

> Catching up with the archives...
>
>> (iv) For the four "changed interpretation" cases, we make it
>> clear that the IDNA2008 interpretation is the important one and
>> that registries have a lot of responsibility here.   However,
>> if an application is in a position to deliver two different
>> answers to the user, then it MAY reasonably do both lookups and
>> then do whatever with them seems appropriate (obviously, a "did
>> you really mean?" dialogue would be one such option).
>>
>> Agreed as well. That, I think, is the only option I've heard for
> handling for whatever characters end up in IDNA 2008 with changed
>> interpretations that would help mitigate the security problems.
>>
>> The specified order of lookup will be important. The did you mean  
>> option
> could be recommended for user-facing code. That isn't, of
>> course, much use for a lot of software like search engines, but for  
>> UIs
> could be useful.
>
> This "two lookups" approach pops up again and again and I have a  
> very bad
> feeling about it. Let me check first if I get the idea right: So the
> suggestion is that a DNS client (or a layer on top of a DNS client)
> produces two outputs, one with let's say the ZWNJ in a domain name  
> mapped
> to nothing, and the other one leaving ZWNJ in it. Then these two  
> labels
> are converted to (two different) Punycode and two DNS lookups take  
> place.
> Then the client compares the DNS answers and if they are different,  
> this
> is handled accordingly (UI interaction, abortion if no user interation
> possible, whatever). Is that right? Because I think this is broken.
>
> First of all, two identical answers are not an unambiguous indicator  
> that
> there are no "security problems". The "real" and the "phishing"  
> webpage
> (let's concentrate for a moment on web for the sake of simplicity)  
> could
> incidentally be hosted on the same server (same IP) by a big  
> registrar.
>
> And there are plenty of operational situations in which *two  
> consecutive
> identical DNS queries can lead to two different replies*:
> * Replies are returned from a cache. Caches naturally change in time.
> * No cache gets involved: One query is sent to one authoritative
> nameserver, the second is sent to a different authoritative  
> nameserver.
> These servers have unfortunately different states of zone content.
> * Or your resolver has sent the two queries to the same nameserver,  
> but
> they are delivered to, for instance, two different anycast instances
> (again with different states of zone content).
> * Or both are delivered to one and the same nameserver instance, but  
> one
> query is dealt with before a content change, the second is dealt with
> after the content change.
> * Or no content changes take place at all, but different answers are  
> sent
> as part of a DNS load balancing scheme.
> If we not only take the answer section of the reply into account for  
> the
> comparison, but also authority and the additional sections, the
> possibilities of something not going as expected grow.
>
> Summary: Different replies to the two lookups is neither a  
> sufficient nor
> a necessary condition for a "security situation", the mechanism  
> produces
> plenty of false positives/negatives, which by themselves, would be  
> very
> difficult to debug. We don't want to go down that path.
>
> Best regards,
> Marcos
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update



More information about the Idna-update mailing list