Re: Browsers and .onion names

On 11/30/2015 12:55 AM, Eliot Lear wrote:
> On 11/30/15 8:07 AM, Alex Rousskov wrote:
>> What if I am not about to query the DNS for a .onion name? What should I
>> [not] do to comply in that case?


> As Mark pointed out, RFCs aren't laws.

True, but irrelevant:

  Developer: What should my Tor-ignorant app do to comply with RFC 7686?
  IETF:      RFCs are are not laws.

or

  Customer:  Does your Tor-ignorant app comply with RFC 7686?
  Developer: RFCs are are not laws.


Contrast those ridiculous dialogs with the ones for .example (RFC 6761):

  Developer: What should my app do to comply with RFC 6761?
  IETF: Do nothing special and you will be compliant.

or

  Customer: Does your app comply with RFC 6761?
  Developer: Yes, it does because it does not treat .example specially.


> We're here because RFC 7686 mentions applications and proxy
> functionality.  In the context of HTTP, one can argue that a forward
> proxy in particular is an agent and in some sense part of the client. 

True, but we would have been here even if RFC 7686 did not mention proxy
and even if HTTP proxies were not clients. The RFC applies its SHOULDs
to *all* applications.


> one also has to
> consider whether forwarding the query itself is dangerous.  That is, can
> the client reasonably trust the proxy?  What happens if the proxy is NOT
> aware of .onion?  Can the client or its user be harmed?  What harm, to
> me, means is whether private information is inadvertently leaked.


> To me the answer is “yes”.

While I might give the same answer, our opinion is irrelevant because
the RFC (the only authority in this case) is not detailed enough to
derive that answer from its text. Based on the RFC text alone, a "no"
answer may also not be unacceptable in many cases (the awkward double
negation is intentional to avoid the implication that the RFC prescribes
a certain answer).

The RFCs opens up 100s of such questions by placing vague requirements
on all applications in the world. You and I came up with just 10 or so
examples. Unfortunately, the RFCs does not give a _generally usable_
answer to all the questions it implicitly asks.


> In other words, the safest thing to do is to drop the request and return
> an error unless the client is specifically aware that the proxy can
> process .onion requests, and it itself is able to deal with the results.

OK, your use cases and not-derived-from-RFC recommendation covers .01%
of possible "uses" of .onion in HTTP proxies. I do not think it is
practical to continue down that path because we may not cover even 80%.


>> Those "desired properties" are left undefined as far as non-Tor
>> applications are concerned so it is difficult for a non-Tor application
>> to know what to do with .onion names (other than not doing a DNS lookup
>> with them -- which is usually best handled by a DNS library anyway).
> 
> Well indeed.  But the question is whether this group can provide
> specific advice for http client and proxy implementations with regard to
> the handling of .onion.  Unless I grossly misunderstand Mark (it's
> happened before), I believe his intent was to determine what that
> handling should be (I don't think he got as far as stating what it
> should be).


Agreed. I believe it would be better to conclude (via appropriate IETF
processes) that the RFC 7686 is flawed than to attempt to issue any
specific HTTP guidance based on a flawed RFC.


Based on the excellent summary by Kari Hurtta, the only sane solution
that I can see is to adjust RFC 7686 wording to say:

"""Application software MAY recognize .onion names as special, or MAY
pass them to name resolution APIs as they would for other domain names."""

and also strongly encourage the RFC authors to actually describe best
"special treatment" practices for applications _outside_ of the DNS
resolution context (e.g., "do not share with untrusted agents", "do not
log", "treat as a clear-text password", etc.).

Adding "do not resolve" to that best-practices list would be OK too, of
course, because it will all come under the "MAY recognize as special"
guard. Note that a general "do not share with untrusted agents"
best-practice mentioned above covers the DNS-specific "do not resolve"
example in all the important DNS resolution cases.


> Amos' point is fair: it's generally not considered okay, and even
> perhaps ridiculous, to place demands on systems that are not intended to
> implement a specification.  But we're here because not doing so has its
> own risks.

To address those risks within HTTP context, this WG may publish its own
draft with the intent to update RFC 7686 when it comes to HTTP
applications. However, given the very general nature of the leakage
problem, it would be much better to solve it once for all applications,
not one draft per protocol/WG!


Cheers,

Alex.

Received on Monday, 30 November 2015 15:38:05 UTC