Subject: Browsers and .onion names

From: Mark Nottingham <[email-masked]>
Date: Thu, 26 Nov 2015 16:29:30 +1100

Now that we have RFC7686, there's a new requirement applicable to HTTP clients:

"""
Applications (including proxies) that implement the Tor protocol MUST recognize .onion names as special by either accessing them directly or using a proxy (e.g., SOCKS [RFC1928]) to do so.  Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup.
"""

Is anyone aware of a browser that does this or plans to do so? 

I've raise an issue for 7230bis:
  https://github.com/httpwg/http11bis/issues/10

--
Mark Nottingham   https://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Nov 2015 07:54:10 +0100

> Applications (including proxies) that implement the Tor protocol MUST recognize .onion names as special by either accessing them directly or using a proxy (e.g., SOCKS [RFC1928]) to do so.  Applica…

I'm surprized that an RFC on standards track managed to redefine how
non-interested implementations must behave :
  - there's this paragraph that you quoted above which affects perfectly
    standards-compliant applications
  - standards-compliant name resolution APIs and resolvers are now
    required to respond with NXDOMAIN if they don't implement the spec
  - caching DNS servers must be modified
  - authoritative servers must respond with NXDOMAIN
  - etc etc ...

Normally they only define the behaviour for compliant ones.

I smell a massive mess here. Had we adopted such a method to force
HTTP/2's on-wire compatibility with HTTP/1 by deciding how current
H1 implementations must behave, we'd have had less difficulties to
build a handshake. Eg: "deployed implementations must suddenly not
do this nor that and it magically works".

There's no way existing implementations will change their deployed
working code just to take in consideration something they're not
interested in, so I don't know what the end result will be when
non-compliant implementations face compliant ones.

Definitely strange form of alternate history :-/

Regards,
Willy

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 26 Nov 2015 12:21:57 +0000

On 11/26/15, Mark Nottingham <[email-masked]> wrote:
> Applications (including proxies) that implement the Tor protocol MUST
> recognize .onion names as special by either accessing them directly or using
> a proxy (e.g., SOCKS [RFC1928]) to do so.  Applications that do not
> implement the Tor protocol SHOULD generate an error upon the use of .onion
> and SHOULD NOT perform a DNS lookup.
> """
>

I believe that the Tor Browser properly implements RFC7686.

All the best,
Jacob

---

From: Mark Baker <[email-masked]>
Date: Thu, 26 Nov 2015 12:08:22 -0500

> non-interested implementations must behave :

Wow, +1. DNS is what it is, but there are ways around it. For example,
by defining a new URI scheme (or set thereof) which defers name
lookups to Tor instead of (or ahead of) DNS.

It's more work up front, but seems far more likely to be successful.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Nov 2015 07:59:39 +1100

> On 27 Nov 2015, at 4:08 am, Mark Baker <[email-masked]> wrote:
> 

This was discussed at length. .onion is much more than that, because it's possible to run not only HTTP, but also XMPP and many other protocols over it. Do we really want an explosion of http-onion, xmpp-onion, etc.? Also, leveraging that into existing software is difficult (mostly because they haven't made protocol schemes a reliable extension point).

Also, the Web already has the concept of a separation between naming and address resolution baked in. RFC7230 Section 2.7.1 says this about hostnames in HTTP URLs:

"""
If host is a registered name, the registered name is an indirect identifier for use with a name resolution service, such as DNS, to find an address for that origin server. 
"""

... which builds on how RFC3986 Section 3.2.2 talks about hostnames in URLs and URIs:

"""
The presence of a host subcomponent within a URI does not imply that the scheme requires access to the given host on the Internet.  In many cases, the host syntax is used only for the sake of reusing the existing registration process created and deployed for DNS, thus obtaining a globally unique name without the cost of deploying another registry. However, such use comes with its own costs: domain name ownership may change over time for reasons not anticipated by the URI producer.  In other cases, the data within the host component identifies a registered name that has nothing to do with an Internet host.  We use the name "host" for the ABNF rule because that is its most common purpose, not its only purpose.
"""

So .onion is just one example of this. Personally, I'd *really* prefer the Web not to be locked into one address resolution protocol (especially when you look at how problematic our current solution can be).

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Nov 2015 11:24:57 +1100

> I believe that the Tor Browser properly implements RFC7686.

Thanks, Jake.

I'm wondering specifically about browsers that don't implement the Tor protocol; so far it looks like they don't conform. A few bugs:

https://bugzilla.mozilla.org/show_bug.cgi?id=1228457
https://code.google.com/p/chromium/issues/detail?id=562265
https://github.com/bagder/curl/issues/543
Apple bug 23672882

I don't have a Windows box on hand, would love it if someone could test there and file a bug if appropriate.

Cheers,

---

From: Mark Baker <[email-masked]>
Date: Thu, 26 Nov 2015 22:09:42 -0500

On Thu, Nov 26, 2015 at 3:59 PM, Mark Nottingham <[email-masked]> wrote:
> This was discussed at length.

News to me, thanks Mark. I've just signed up for DNSOP to follow
along. My initial impression from reviewing recent messages is that
the discussion is ongoing rather than settled.

> .onion is much more than that, because it's possible to run not only HTTP, but also XMPP and many other protocols over it. Do we really want an explosion of http-onion, xmpp-onion, etc.? Also, leveraging that into existing software is difficult (mostly because they haven't made protocol schemes a reliable extension point).

I wouldn't call a doubling of a small number an explosion. Considering
the magnitude of what Tor is trying to accomplish, the price doesn't
seem too much of a burden.

But I'll take this to DNSOP after spending some quality time with the
archives. I encourage others to do the same.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Nov 2015 14:47:51 +1100

> On 27 Nov 2015, at 2:09 pm, Mark Baker <[email-masked]> wrote:
> 

I meant in the case of .onion, which has an RFC now. The current question is what to do for others.

---

From: "Walter H." <[email-masked]>
Date: Fri, 27 Nov 2015 05:25:32 +0100

Does this really make a sense?

because of the many new TLDs, there would be no reason to handle any 
special;

www.recipes.onion

could be a nice site about cooking with onions ...

Walter

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Nov 2015 08:41:04 +0100

> I don't have a Windows box on hand, would love it if someone could test there and file a bug if appropriate.

So are we going to scan each and every DNS client that was written in the last
30 years and suddenly declare them non-compliant with a new standard that was
written *after* them and not specifically for them ?

I mean, I think it's really the first time I'm seeing bugs filed at products
for not complying with a spec they do not implement!

Similarly we could write an RFC describing how HTTP over SCTP works and then
file bugs at every HTTP client because they don't implement SCTP! That really
doesn't make sense Mark, I'm sorry. When you don't support a protocol, you
don't have any reason for having to implement its specification!

That's why I think this standard was written the reverse way : instead of
scratching one's head trying to adapt to existing infrastructure, let's
redefine how existing infrastructure should have been working and declare
all offenders bogus. I'm seeing a failure here. And the simple fact that
you started to file bugs at existing products is a proof, you will never
find all "offenders" because they work the natural way, by implementing
what they are interested in and not an exception for some obscure protocol
mentionned in an RFC they don't even know exist.

What could possibly have worked would have been to declare an addition on
top of DNS to make it possible for clients and forwarders to declare
exceptions to TLDs and make them configurable. Then this spec for Tor would
simply have relied on this and recommended to add ".onion" to the list of
exceptions. And it would have planned the fallback situation for when parts
of the infrastructure do not implement it.

Last point, given that many companies register their own names as TLDs, I
don't see why it wouldn't have been easier to register .onion as a TLD and
adjust the specification to handle this correctly.

Regards,
Willy

---

From: Cory Benfield <[email-masked]>
Date: Fri, 27 Nov 2015 08:32:32 +0000

> On 27 Nov 2015, at 07:41, Willy Tarreau <[email-masked]> wrote:
> 

I agree with Willy here, sadly. I have absolutely no intention of adding this exception for .onion names to any software I work on.

Why is this the DNS client’s problem? If we really don’t want .onion names to leak over DNS, why don’t we add a new DNS RFC that specifies that conformant resolvers don’t emit queries for .onion names?

Also, as the RFC points out:

> Also, users need to understand the difference between a .onion name
> used and accessed directly via Tor-capable software, versus .onion
> subdomains of other top-level domain names and providers (e.g., the
> difference between example.onion and example.onion.ld).

Given that the DNS search path exists, how am I (a client that accepts URLs) supposed to know whether “some-url.onion” is meant to be a Tor onion URL, or whether the user expects the search path to be appended to get to “some-url.onion.corp.org”. Am I to require that previously working URLs now fail because they *might* be a valid .onion name, even though the user can’t reasonably expect to *reach* that name through the Tor protocol using my software because I don’t implement it?

As Willy points out, it is *crazy* to open bugs that say that “your implementation does not comply with an RFC it does not implement”. That is true of all software ever written. Never before have we had a normative requirement to comply with RFCs we do not implement.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 28 Nov 2015 10:40:32 +1100

Hi Cory,

> On 27 Nov 2015, at 7:32 pm, Cory Benfield <[email-masked]> wrote:
> 

7686 requires both resolvers and applications to stop emitting queries for .onion names. This is defence in depth; updating DNS resolvers takes time, so applications that care about their users' privacy will assure that those queries are stopped earlier.

You can certainly choose not to implement RFC7686 (there are no RFC police), and there won't be any reduction in interoperability, just security (due to the leakage of requests).

That said, I don't see how it serves your users well to reject it out of hand. If they accidentally make .onion queries without configuring to use Tor, they'll be unpleasantly surprised (and the consequences could be much worst, depending on their situation).

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 28 Nov 2015 07:29:05 +0100

Hi Mark,

On Sat, Nov 28, 2015 at 10:40:32AM +1100, Mark Nottingham wrote:
> That said, I don't see how it serves your users well to reject it out of
> hand.

It's not rejecting *this one* specifically, it's starting to add exceptions
for everything even when you're not targetting a specific usage. This opens
a pandora box. Now there is one exception. Next year maybe we'll have tens.
And possibly some of them will conflict with internal names. A lot of people
use ".local" as the TLD for their local network. Someone might suddenly
decide that ".local" must not be forwarded nor resolved for whatever reason
and suddenly all compliant agents will break existing setups. You know better
than any of us that a cleanly designed protocol doesn't require existing
implementations to change to serve its purpose.

> If they accidentally make .onion queries without configuring to use
> Tor, they'll be unpleasantly surprised (and the consequences could be much
> worst, depending on their situation).

So that basically means that Tor is unsafe without this ? Thus maybe using
this DNS mechanism was a poor choice to start with, and it's a bit late to
change all DNS agents just to fix the protocol's design issues.

Regards,
Willy

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 28 Nov 2015 09:53:06 +0000

> implementations to change to serve its purpose.

Uh, I'm not sure if you're telling a joke or not but this entire
process started because of .local as a Special-Use-Domain-Name:

  https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

Thus the Pandora's box opened up without notice, I guess? Perhaps it
is time to implement them both?

In any case, yes, we have Special-Use-Domain-Names and there is a list
that some applications need to handle in a special manner. The IETF
seems to be blocking all other new Special-Use-Domain-Names, so the
flood you've express concern about is unlikely to happen.

> change all DNS agents just to fix the protocol's design issues.

No, Tor is safe and complies with RFC7686. Other browsers and software
that leak .onion names are now understood to be unsafe. Just as time
moved on, many browsers don't implement HTTP 2. Or browsers which
still use SSLv2/SSLv3.

There are lots of changes happening in browsers - this is no different
- it is a security and privacy concern. It has been identified as a
concern that we can resolve by following RFC7686, no pun intended.
Browsers SHOULD implement it but as Mark has said: we have no RFC
police.

( I'm one of the authors of RFC7686, sorry for the hassle; we're
trying to protect users who don't understand complicated things like
XKeyscore and mass-surveillance and encryption and so on. )

All the best,
Jacob

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 28 Nov 2015 11:09:59 +0100

Hi Jacob,

On Sat, Nov 28, 2015 at 09:53:06AM +0000, Jacob Appelbaum wrote:
> > A lot of people

I didn't even know it was reserved. Once browsers start to block it, I know
quite a number of people who will report breakage such as inability to access
internal resources in their companies. Locally-administered TLDs are a missing
feature to complement RFC1918 but that's out of the scope of this discussion.

> flood you've express concern about is unlikely to happen.

Fine, at least the mess will be limited.

> that leak .onion names are now understood to be unsafe.

So if they're safe, why should they implement this ?

> Just as time

But you understand the trouble and precedent it's setting up ? "yes I
know you're not interested in this protocol but despite this you should
implement its RFC". I could as well suggest that for the sake of any
protocol of mine, browsers take care to send even number of bytes in
any request and that proxies should block requests containing an odd
number of bytes.

I think it would be easier to suggest browsers to support a blacklist
of TLDs that should not be resolved nor passed to proxies and then let
users decide what TLDs they want to block. Those who use .onion addresses
probably know it.

Regards,
Willy

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 28 Nov 2015 11:56:56 +0000

Dear Willy,

> feature to complement RFC1918 but that's out of the scope of this

I think that .local is reserved by RFC6762 which is around two and a
half years old. Most Apple computers have been using .local for mDNS
related stuff for a lot longer, which is how .local was reserved by
Apple in the first place. Most GNU/Linux systems with systemd also use
.local.

Will it break stuff? No, probably not, as the way .local is handled is
such that absent infrastructure, it Just Works (TM). Will it conflict
with other systems? Probably sometimes.

Does that mean .local is going away and that we need to ignore how it
is being used? I don't think so....

Does it mean that local admins who picked .local are probably sad
about that choice? Yes, I suspect you are correct, it would.

What shall we do here? Abandon all Special-Use-Domain-Names? What
about the other dozen? And why shall we do that?

> Fine, at least the mess will be limited.

That isn't a certain thing just a temporary thing. There is work
underway to revise the process for Special-Use-Domain-Names. I
personally hope that .gnu and others will become
Special-Use-Domain-Names.

> So if they're safe, why should they implement this ?

Tor is safe. The thing that isn't safe is users attempt to resolve
host names that they are incapable of resolving. We should not pollute
the root servers with such queries and we should fail closed to
protect users. The mere queries of the label may be problematic as we
explained in our RFC...

We explained this in RFC7686 - if you read it and it is unclear, I'm
happy to clarify further; I'd rather not repeat that RFC in full
here...

> any request and that proxies should block requests containing an odd

I hear and understand your concerns.

Could you propose a counter proposal for how to keep users safe as we
have done in RFC7686?

I'd be happy to support such an RFC and in two years, we'll probably
have a similar discussion about your proposal from different
stakeholders. :-(

> users decide what TLDs they want to block. Those who use .onion addresses

And when a browser pre-fetches a list of urls, did the user know they
were a .onion user? No, of course not. There are dozens of similar
situations. We solve a real problem with RFC7686 and browsers, as well
as other software, have a duty of care to implement the solution. It
is a free choice, of course. There are no RFC police, only software
that is compliant with relevant RFCs or not.

Hope that helps,
Jacob

---

From: Cory Benfield <[email-masked]>
Date: Sat, 28 Nov 2015 16:59:02 +0000

> On 28 Nov 2015, at 11:56, Jacob Appelbaum <[email-masked]> wrote:
> We solve a real problem with RFC7686 and browsers, as well
> as other software, have a duty of care to implement the solution.

The browsers part makes sense to me, it really does, and I (and maybe Willy) would not have objected in the slightest if this was brought up as a suggestion instead of what felt like a mandate. I don’t object to browsers refusing to process .onion domains, that makes perfect sense. I care much more about claiming that the requirement extends to anything that processes domain names (your “other software", even if that application makes no claim to support Tor or actively claims it does not.

It is worth remembering that the space of things an piece of software does not implement is far larger than the space of things it does. It is a difficult and fraught endeavour to try to mandate behaviour in implementations whose authors had no reason to read your RFC because they had no plans to go anywhere near the Tor protocol.

It’s also unhelpful to claim that all software that does DNS lookups has a duty to filter out .onion URLs to save users from themselves. This requirement is prima facie absurd: are we to require that, for example, Python’s logging library should filter .onion URLs in case a user tries to put a syslog daemon behind such a domain? Or, a more extreme case, that RADIUS implementations should do so? Remember, any RADIUS application is an “application that does not implement the Tor protocol”, so RFC 7686 would appear to affect those as well. This is so obviously absurd that I assume that it was not the intent of RFC 7686, but RFC 7686 is certainly worded so broadly that it can be read that way.

There is nothing wrong with wanting browsers to filter .onion domains, because browsers can be extended to support the Tor protocol. There’s nothing wrong with wanting tools that could in principle support the Tor protocol, or that do not rule out doing so, to also special case the .onion domain. It is, however, totally barmy to claim a normative requirement on all DNS applications to filter out .onion domains and to (presumably) use that requirement as a cudgel to punish them with if they do not. Many applications that process domain names come nowhere near a protocol or use that Tor is intended for, and shouldn’t be bound by this requirement. At some point, we have to rely on users not to just throw .onion names into every settings field they find.

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 28 Nov 2015 23:33:07 +0100

On Sat, Nov 28, 2015 at 04:59:02PM +0000, Cory Benfield wrote:
> The browsers part makes sense to me, it really does, and I (and maybe Willy)
> would not have objected in the slightest if this was brought up as a
> suggestion instead of what felt like a mandate. I don???t object to browsers
> refusing to process .onion domains, that makes perfect sense. I care much
> more about claiming that the requirement extends to anything that processes
> domain names (your ???other software", even if that application makes no
> claim to support Tor or actively claims it does not.
(...)

I confirm that it was my point as well. Thanks Cory for making it
clearer than I did :-)

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 28 Nov 2015 23:52:52 +0100

> about the other dozen? And why shall we do that?

No, just register some permanent and reliable names. RFC6762 suggested
that a number of people were using .local prior to the RFC and would be
bothered. It suggests to use other TLDs instead such as .lan, .private
etc... None of them is reserved, and there's even an errata on the RFC
now suggesting to remove this suggestion to avoid breaking setups a
second time. All it shows is that declaring breakage *after* a standard
is a bad thing for users and is a proof of poor initial design.

> protect users.

OK so that's less dramatic than what Mark appeared to think if
implementations do not obey this spec that they're not necessarily
going to read.

> The mere queries of the label may be problematic as we
> explained in our RFC...
> 

I've mostly spent time on the parts that were declaring existing
implementations non-compliant if they didn't apply these new rules, I
didn't read everything.

> have a similar discussion about your proposal from different

No but I'm not going to play that game consisting in saying "look I did
my part of the job, if it doesn't suit you please provide something better".
I'm not the guy in charge for this protocol, I'm not the one responsible
for finding and validating all the possibilities. All I'm seeing is that
it declares suddenly non-compliant some components that previously were
compliant and that it's not the best way to get a standard applied for
real in field.

> that is compliant with relevant RFCs or not.

Except that here it's mandated that software that does not implement
the protocol must comply with this spec for the sake of the protocol.
That's quite a confusing approach.

Regards,
Willy

---

From: "Adrien de Croy" <[email-masked]>
Date: Sat, 28 Nov 2015 23:00:49 +0000

is there also a requirement for sub-domains of .onion to not do things 
like set up MX records and run mail servers?

I can't imagine how many thousands or millions of deployed DNS servers 
and resolvers and other network software out there will happily forward 
.onion lookups.  Good luck to anyone trying to get those redeployed.

It seems to break the principle rule of specs, that is if you don't 
implement it you don't have to implement it.

Requiring someone who isn't implementing a spec to implement the spec is 
not only logically flawed, it's practically flawed and is not a sane 
strategy IMO.  It reminds me of the law the EU passed a while back 
requiring all merchants selling into the EU to collect and remit VAT - 
making extra-judicial laws turning innocent net vendors into your tax 
agent.  A law (since I don't fall under EU jurisdiction) I promptly 
ignored after checking with the NZ ministry.  Tor does not get to have 
jurisdiction over all internet products sorry.

That only really leads to one conclusion and that is that special use 
domains were always a bad idea, and adding more is a worse idea, and 
they should just be deprecated.  I see a lot of DNS lookups for .local 
floating around and it doesn't seem to break anything.

Adrien

------ Original Message ------
From: "Willy Tarreau" <[email-masked]>
To: "Cory Benfield" <[email-masked]>
Cc: "Jacob Appelbaum" <[email-masked]>; "Mark Nottingham" 
<[email-masked]>; "HTTP Working Group" <[email-masked]>
Sent: 29/11/2015 11:33:07 a.m.
Subject: Re: Browsers and .onion names

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 29 Nov 2015 10:27:32 +1100

Cory,

> On 29 Nov 2015, at 3:59 am, Cory Benfield <[email-masked]> wrote:
> 
> 
> There is nothing wrong with wanting browsers to filter .onion domains, because browsers can be extended to support the Tor protocol. There’s nothing wrong with wanting tools that could in principle support the Tor protocol, or that do not rule out doing so, to also special case the .onion domain. It is, however, totally barmy to claim a normative requirement on all DNS applications to filter out .onion domains and to (presumably) use that requirement as a cudgel to punish them with if they do not.
>  
> Many applications that process domain names come nowhere near a protocol or use that Tor is intended for, and shouldn’t be bound by this requirement. At some point, we have to rely on users not to just throw .onion names into every settings field they find.

Wait a minute -- you agree that the requirement is being placed specifically upon DNS applications, and then its application to things that have nothing to do with DNS. Has anyone actually been saying that .onion should be (e.g.) filtered out of logs?

Is this just a misunderstanding about the word "use" in the text below?

"""Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup."""

... because I (and I think most others) read that as being in the context of the operation of the DNS protocol (given the nature of the registry).

Cheers,

---

From: Alex Rousskov <[email-masked]>
Date: Sat, 28 Nov 2015 18:24:07 -0700

> Now that we have RFC7686, there's a new requirement applicable to HTTP clients:

That requirement is for RFC 7686 applications, not HTTP applications. If
some HTTP applications decide to comply with RFC 7686, then they may do
so, of course, but that decision has pretty much nothing to do with HTTP.

Proof: If the requirement were to apply to all HTTP clients, RFC 7686
would have been marked as "updating" HTTP (and 100s of other protocols
with RFCs).

The discussion should probably stop here because the problems with that
RFC are not related to HTTP.

> Is this just a misunderstanding about the word "use" [...]?

...

> I (and I think most others) read that as being in the context of the
> operation of the DNS protocol (given the nature of the registry).

Is routing all HTTP requests for .onion URLs to a
big-brother.example.com HTTP proxy considered "use", even if there are
no DNS operations involved?

Is logging details of all HTTP requests for .onion URLs in a special
NFS-mounted big-brother.log file considered "use", even if there is no
DNS operations involved?

AFAICT, given the presumed nature of the problem, RFC 7686 ought to
cover any sharing of the domain name with services outside application
control (including log processing services, some HTTP peers, and DNS
servers). DNS lookup is just one [common] example of using such services.

Alex.

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 29 Nov 2015 16:34:25 +1300

On 29/11/2015 12:27 p.m., Mark Nottingham wrote:
> Cory,
> 
>> On 29 Nov 2015, at 3:59 am, Cory Benfield wrote:
>>
>>
>>> On 28 Nov 2015, at 11:56, Jacob Appelbaum wrote:

No. I dont think so. For several reasons:

Requirement #1 is very arrogantly placed upon *human* behaviour.
  In what countries will this RFC be enshrined in national laws? and who
is going to enforce it?

Requirement #2 is placed upon "Application Software". The fact that it
is speaking of *all* application software is clear by calling out
proxies and browsers as being part of the group, and the split outlining
separate requirements #3-#7 for DNS implementation types.

For a case study:

Squid does *not* implement Tor. Which means that we SHOULD under this
protocol return an error page for .onion requests.

However, we do proxy anything by tunnelling. As per CONNECT method
definition.

Over the past few weeks there have been a growing number of user
complains about how their proxy is not working when used by browsers
configured to use Squid proxy to (securely) relay requests to a
Tor-enabled proxy / gateway.

As for .local being a precedent. It *is* perfectly valid for a LAN DNS
resolver to implement .local diversion. And for any software that does
not implement .local gatewaying to simply ask its local resolver for
those .local names.
This .onion RFC is actually forbidding that demonstrated working
behaviour by .local from being used to fix .onion problems.

HTH
Amos

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 29 Nov 2015 16:50:02 +1300

> servers). DNS lookup is just one [common] example of using such services.

Very good questions. Note that...

If you can answer "yes" to any of them, there are MUST that need to be
complied with.

If you answer "no" to all of them, there are SHOULD that need to be
complied with,

Under no circumstances is non-implementation (non-compliance) of this
RFC permitted (by it, and it alone). And people are starting to file bug
reports about that against HTTP agents. See the problem?

Amos

---

From: Cory Benfield <[email-masked]>
Date: Sun, 29 Nov 2015 09:52:40 +0000

> On 28 Nov 2015, at 23:27, Mark Nottingham <[email-masked]> wrote:
>> 

Mark,

I’m sorry if I was insufficiently clear. When I said “rely on users not to just throw .onion names into every settings field they find”, I specifically meant that many applications have settings fields that allow users to provide names that will be looked up. For example, at my previous employer we had a RADIUS implementation that would talk over the network, and so would emit a DNS lookup. Are we really saying that that software should be filtering .onion names because a telco operator *might* put a .onion name into the “RADIUS server” configuration field?

The answer, of course, is no: and to be clear, I’m not accusing your or Jacob of making that claim. I don’t believe the intent of the RFC was ever to make such a claim. However, the way the RFC is worded it *does* say that.

Again, I think with regard to *browsers* the advantage in implementing this requirement is clear, and I don’t object to it. I think with regard to curl the argument may apply too: it would be reasonable to want to enhance curl to talk over the Tor protocol. I think with regard to almost every other networked software application the SHOULD (NOT) is absurdly over-broad, and places a strong burden on them to defend against a user error that is extremely unlikely (the error, to be clear, is assuming the application can speak Tor).

I’m all for removing foot-guns, but at some point we need to accept that the value proposition does not extend as far as RFC 7686 wants it to: if all software really does need to defend against users speculatively adding .onion names to any configuration that accepts a domain then we’re clearly fighting a losing battle.

Cory

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 29 Nov 2015 20:58:46 +1100

Hey Cory,

> I’m all for removing foot-guns, but at some point we need to accept that the value proposition does not extend as far as RFC 7686 wants it to: if all software really does need to defend against use…

I think that's a fair position; just a bit surprised at the vehemence of the response from everyone. While 7686 could have been a lot more precise in that phrasing, I think the assumption was that software where it didn't make sense would just ignore that text (or the whole RFC).

After all, despite our best efforts, there still are no standards police.

If it's really bugging people, we can try to get an errata in, but I suspect the wording is going to be tricky, and likely quite verbose.

Cheers,

---

From: Richard Hartmann <[email-masked]>
Date: Sun, 29 Nov 2015 12:56:45 +0100

> If it's really bugging people, we can try to get an errata in, but I suspect the wording is going to be tricky, and likely quite verbose.

It's not bugging me.

That being said, what about the reasonably opaque "implementors who
can reasonably expect some of their users to use Tor-enabled services
[and/or to use .onion addresses by accident] etc. pp." as a middle
ground?

Richard

---

From: Eliot Lear <[email-masked]>
Date: Sun, 29 Nov 2015 19:45:50 +0100

Hi Cory,

> I’m sorry if I was insufficiently clear. When I said “rely on users not to just throw .onion names into every settings field they find”, I specifically meant that many applications have settings fi…

I'm still not entirely clear on what the concern is.  I *think* what is
being said is the following:

 1. .onion requires special handling.
 2. If you don't know how to handle it, pass an error back to the user.
 3. If you're about to query the DNS for a .onion name, then you don't
    know how to handle it.

Whether this is with a browser or curl or something else, that seems to
make sense to me.  I could easily envision a proxy that can handle
.onion.  That means one might never get to step 3 if you're using a proxy.

Or have I missed the point?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sun, 29 Nov 2015 22:07:50 +0100

> would have been marked as "updating" HTTP (and 100s of other protocols

This puts more stock in IETF document practices than is probably worthy
of calling a proof.  I would rather we examine the issue from a
pragmatic approach such that unnecessary and/or dangerous queries are
suppressed at the appropriate level.

Eliot

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 30 Nov 2015 00:56:08 +0000

what bugs me is this.

from draft-adpkja-dnsop-special-names-problem section 5 para 2

"In the case of [I-
D.ietf-dnsop-onion-tld], leakage of ONION queries on the Internet
might lead to disclosure of private information that, in some cases,
might pose a risk to the personal safety of end-users"

ok, so we're designing a protocol (onion TLD) in which badness can 
happen if lookups leak over the internet, and yet we expect the hundreds 
of millions of DNS resolvers out there to magically travel back in time 
and implement RFC6761 (from 2013) thereby treating the TLD as a 
"protocol switch" for resolution, even though the concept didn't exist 
when they were written.

It seems to me that relying on all these resolvers to be updated to not 
remain a security problem is completely bonkers.

Also it seems that the justification for adding new special use TLDs was 
the existence of "localhost" and ".local".  "localhost" has been in use 
for decades, and .local is NOT solely for MDNS as claimed, it's also 
used by unicast DNS on many corporate networks. These are not examples 
of protocol switching.

It also bugs me that the first para states there is IETF consensus on 
this.  for protocols with as wide ranging effect as this, maybe 
consensus should be required from a bigger group than just dnsop WG.

Adrien

------ Original Message ------
From: "Richard Hartmann" <[email-masked]>
To: "Mark Nottingham" <[email-masked]>
Cc: "Cory Benfield" <[email-masked]>; "Jacob Appelbaum" 
<[email-masked]>; "Willy Tarreau" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 30/11/2015 12:56:45 a.m.
Subject: Re: Browsers and .onion names

>>  If it's really bugging people, we can try to get an errata in, but I 
>>suspect the wording is going to be tricky, and likely quite verbose.
>
>It's not bugging me.
>

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 30 Nov 2015 14:48:54 +1300

> Or have I missed the point?

Legacy install base. Old code of non-Tor applications always does (3).

What is being said is not what is being required.

If the application does not know how to handle FQDN (or something that
is indistinguishable from a public FQDN). Then it will not be going to
DNS, so is not a problem and will do #2 automatically anyway.

If it does know how to handle public FQDN (whether directly or via
third-party APIs), but was never coded to implement this RFC. Then it is
a problem, and is required to immplement this RFC.

 ... Doing either of step #2 and #3 *is* implementing this RFC.

Ergo, if one does not implement this RFC, one is required (MUST or
SHOULD) to implement this RFC.

Ridiculous situation. Everybody get to laugh at DNSOP.

This really does seem to be a problem that resolvers are the best placed
to fix. If a non-Tor application tries to resolve .onion and gets
NXDOMAIN or other error back. Then it is highly likely to handle that
appropriately by delivering an error to the user.
 No need to place special requirements on such applications in the first
place. They can and will just ignore this RFC.

Amos

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 30 Nov 2015 00:07:54 -0700

> Or have I missed the point?

AFAICT, the biggest one is that the correct "special handling" by
non-Tor applications is undefined. You have [essentially] said "If
you're about to query the DNS for a .onion name, then pass an error back
to the user instead". This instruction is missing the "else" clause:
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 my earlier questions attempted to show, there are many areas where
there is no DNS lookup but there may be leakage, and it is not clear
whether that leakage complies with or violates the spirit of RFC 7686.

While the RFC claims that

""".onion names are "special" [because] they require hardware and
software implementations to change their handling in order to achieve
the desired properties of the name."""

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

If the RFC can be adjusted to limit its scope to DNS lookups, everything
will become clear AFAICT, but I do not know whether that narrow
interpretation would still prevent the leaks that Tor folks want to prevent.

Alex.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 Nov 2015 08:55:03 +0100

Alex, thanks for your clarification.  Please see below.

> [not] do to comply in that case?

As Mark pointed out, RFCs aren't laws.  There are only goals beyond core
functionality:

  * Interoperability
  * Security

The special use registry needs to address both (IMHO); but then going
beyond that people need to address the concern in specific contexts. 
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. 
Mark occasionally uses a term like split browsers.  In those contexts,
the amount of semantic processing capability of the browser may be so
limited that the responsibility for keeping the query off the network
shifts to the proxy.  But in considering that aspect, 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”.

Hence, I conclude that one should be cautious about sending queries
ending in ".onion" and having some discovery mechanism for, say, proxy
functioning of such names.  This is especially the case with .onion
names which have the service name in them and might require
substantially more processing in the proxy than might otherwise be
performed.  One might view .onion in the same light as a recursive SOCKS
proxy.

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.

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

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.

> The presence of a host subcomponent within a URI does not imply that the scheme requires access to the given host on the Internet.  In many cases, the host syntax is used only for the sake of reusi…

If memory serves this was stated as such because we were in essence
using URIs as names where the URI was never intended to be resolved, but
yet guaranteed to be unambiguous as to its meaning (e.g. XML name
spaces).  While there's no hard and fast rule about naming on the
Internet, alternative name spaces pose their own set of problems.  For
one thing, they leak.  That was a major part of the impetus of RFC 7686,
and the RFCs that established the registry.

And so to this point:
> Personally, I'd *really* prefer the Web not to be locked into one address resolution protocol (especially when you look at how problematic our current solution can be).

While "locked into" might not be what I want either, the benefit of
using a single address resolution protocol is that there is inherent
consistency.  Those publishing a name do so in one way for which it is
assumed that the client understands.  That is quite powerful.  The
limitation is that it is *incredibly* hard to evolve that mechanism due
to its ossification.  They are yin and yang.  If that sounds like I'm
divided on this issue, you've then you've understood my meaning.  I
would suggest it is not black and white and that there are tradeoffs.

So... pragmatically, what is appropriate?

Eliot

---

From: Cory Benfield <[email-masked]>
Date: Mon, 30 Nov 2015 08:16:59 +0000

> On 30 Nov 2015, at 01:48, Amos Jeffries <[email-masked]> wrote:
> 

Which is a substantial part of the problem, because the legacy install base is actually *every DNS-using piece of software ever deployed*, minus anything that already implements Tor. That is a sizeable base of software. As I said earlier, it’s a much larger space of software than the space of DNS resolvers, which are also the natural place to fix this problem in the software stack.

The complaint has never been that the requirement not to leak .onion names is bad. The complaint is that chasing applications up for this in the RFC is a poor fix. *Resolvers*, which already have an incentive to implement the RFCs that come from DNSOP, are the perfect place to do it, and fixing those will have the effect of propagating the correct behaviour transparently to applications.

It’s totally reasonable for active projects with large resources (e.g. web browsers) to make an effort to improve this *right now*, but otherwise it seems a terrible misallocation of resources to pressure applications to fix what the resolver should.

In practice, Mark raised his issues only against browsers (and curl, which may be a special case because curl implements nearly every protocol ever designed and it’s reasonable that Tor might want to be one of them). That, I think, is reasonable. The push-back is coming from maintainers of other applications who quite reasonably believe that the RFC applies to them, but think it shouldn’t.

IMO, the normative language should have applied to resolvers and been a MUST. The application directive should either have been non-normative or should have been MAY, providing guidance for developers of applications where the risk of users accidentally providing a .onion name is high (or at least moderate). Unfortunately, the horse has already bolted. We could prepare an erratum, but Mark has suggested that the value of that would not be very high.

Frankly, I think the main thing we get out of this is a learning experience. This is why RFC authors need to restrict their normative language to things that can be enforced/detected by compliant implementations. Any other use of normative language is just to make the author feel better, rather than something that will actually get done. It’s incredibly tempting to have broad-scoped unenforceable normative directives: I seem to recall Martin shooting down a number of them over the course of the writing of RFC 7540. I’m now personally much happier with why we shouldn’t.

Cory

---

From: Kari Hurtta <[email-masked]>
Date: Sun, 29 Nov 2015 08:33:09 +0000

> is time to implement them both?

There is no requirements for applications because "local" is  special use domain name. 
Application is supposed to pass "local" to resolver library.

example             RFC6761 : Application software SHOULD NOT recognize example names as 
                             special and SHOULD use example names as they would other domain 
                             names.
example.com         RFC6761 :  -"- 
example.net         RFC6761 :  -"- 
example.org         RFC6761 :  -"- 
invalid             RFC6761 : Application software MAY recognize "invalid" names as special 
                             or MAY pass them to name resolution APIs as they would for other
                             domain names.
local               RFC6762 : Application software may use these names as they would other similar
                             DNS names, and is not required to recognize the names and treat them
                             specially.
localhost           RFC6761 : Application software MAY recognize localhost names as special, or MAY
                             pass them to name resolution APIs as they would for other domain
                             names.
onion               RFC7686 : Applications that do not implement the Tor protocol SHOULD generate an
                             error upon the use of .onion and SHOULD NOT perform a DNS lookup. 
test                RFC6761 : Application software SHOULD NOT recognize test names as special 

Note "onion" here. That is only special use domain name which
applications are requested recognize as special.

"invalid" and "localhost" are allowed to applications to recognize 
as special, but that is not requested.

Most special use domain name applications are supposed not to
be recognized as special.

For resolver libraries rules are different.

/ Kari Hurtta

---

From: Matthew Kerwin <[email-masked]>
Date: Mon, 30 Nov 2015 19:52:09 +1000

On 30 November 2015 at 17:55, Eliot Lear <[email-masked]> wrote:

>
> And so to this point:
>
> Personally, I'd **really** prefer the Web not to be locked into one address resolution protocol (especially when you look at how problematic our current solution can be).
>
>
> While "locked into" might not be what I want either, the benefit of using
> a single address resolution protocol is that there is inherent
> limitation is that it is *incredibly* hard to evolve that mechanism due to
> its ossification.  They are yin and yang.  If that sounds like I'm divided
> on this issue, you've then you've understood my meaning.  I would suggest
> it is not black and white and that there are tradeoffs.
>
> ​
​Looking at this from the outside, my question is: how do you know how to
resolve a "host"? We've said this:

   If the host identifier is provided as an IP address, the origin
   server is the listener (if any) on the indicated TCP port at that IP
   address.  If host is a registered name, the registered name is an
   indirect identifier for use with a name resolution service, such as
   DNS, to find an address for that origin server.

As an application author, that seems to use the same sort of words and
provides the same sort of level of detail as getaddrinfo, my man page for
which says:

   ... "node" specifies either a numerical network
   address (for IPv4, numbers-and-dots notation as supported by
   inet_aton(3); for IPv6, hexadecimal string format as supported by
   inet_pton(3)), or a network hostname, whose network addresses are
   looked up and resolved.

It never says *how* they're looked up and resolved, the same way RFC 7230
never says how we're supposed to. Perfect! Obviously, if I was writing
a tor thing I'd probably go out of my way to detect .onion addresses and do
special magic; but I'm just writing a boring old HTTP library. I've never
even heard of tor. That's something to do with Frodo and Gollum, isn't it?

If I had faith in my subsystems, I'd assume that getaddrinfo knows
the special doodads for which to watch when given a non-IP-address "node",
and thus know how to resolve it using the appropriate whatchermacallits.
(Similarly to how it already knows that "1.2.3.4" and "[1::2]" are IP
addresses.) So, should we be filing bug reports against Linux, to update
its getaddrinfo syscall?

Aside: I still find it kind of funny that we have an RFC that basically
says: If you implement this spec and the Tor protocol, do this; however if
you implement this spec but not the Tor protocol, do that. (And the
implied: If you don't implement this spec, ¿lol?)

Not wrong, per se, just kind of funny.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 30 Nov 2015 08:37:34 -0700

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

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

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

> handling should be (I don't think he got as far as stating what it

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.

> implement a specification.  But we're here because not doing so has its

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.

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 30 Nov 2015 18:17:50 +0000

bear in mind also not all internet software uses the system's resolver.

It was fairly common for mail delivery software to do its own resolution 
(e.g. craft UDP packets etc) in order to perform MX lookups.

It's also common for customers to remove all resolution capability of an 
underlying host for various reasons (e.g. to prevent malware from having 
connectivity by name), and the proxy does its own resolution (WinGate 
has had its own resolver for well over a decade).

So relying on OS vendors to patch resolvers is probably going to catch a 
lot less than you might think.

Sure I could put handling (e.g. return NXDOMAIN) for .onion in our 
resolver, but it seems like a fairly nasty hack and it's not scalable - 
when will some other special use domain come along and become a problem 
like this.  Every time one is added, every resolver needs to be updated. 
  Also what about every DSL/NAT on the planet which does DNS forwarding.  
You really expect those to be updated for this?  It's just not 
happening.

Personally I think it should have been possible to solve authentication 
and discovery issues for Tor in ways other than overloading DNS like 
this.  And sanctifying such overloading with RFC6761 seems a move in the 
wrong direction to me.

Adrien

------ Original Message ------
From: "Cory Benfield" <[email-masked]>
To: "Amos Jeffries" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 30/11/2015 9:16:59 p.m.
Subject: Re: Browsers and .onion names

>>>>  I’m sorry if I was insufficiently clear. When I said “rely on users 
>>>>not to just throw .onion names into every settings field they find”, 
>>>>I specifically meant that many applications have settings fields 
>>>>that allow users to provide names that will be looked up. For 
>>>>example, at my previous employer we had a RADIUS implementation that 
>>>>would talk over the network, and so would emit a DNS lookup. Are we 
>>>>really saying that that software should be filtering .onion names 
>>>>because a telco operator *might* put a .onion name into the “RADIUS 
>>>>server” configuration field?
>>>
>Which is a substantial part of the problem, because the legacy install 
>base is actually *every DNS-using piece of software ever deployed*, 
>minus anything that already implements Tor. That is a sizeable base of 
>software. As I said earlier, it’s a much larger space of software than 
>the space of DNS resolvers, which are also the natural place to fix 
>this problem in the software stack.
>
>The complaint has never been that the requirement not to leak .onion 
>names is bad. The complaint is that chasing applications up for this in 
>the RFC is a poor fix. *Resolvers*, which already have an incentive to 
>implement the RFCs that come from DNSOP, are the perfect place to do 
>it, and fixing those will have the effect of propagating the correct 
>behaviour transparently to applications.
>
>It’s totally reasonable for active projects with large resources (e.g. 
>web browsers) to make an effort to improve this *right now*, but 
>otherwise it seems a terrible misallocation of resources to pressure 
>applications to fix what the resolver should.
>
>In practice, Mark raised his issues only against browsers (and curl, 
>which may be a special case because curl implements nearly every 
>protocol ever designed and it’s reasonable that Tor might want to be 
>one of them). That, I think, is reasonable. The push-back is coming 
>from maintainers of other applications who quite reasonably believe 
>that the RFC applies to them, but think it shouldn’t.
>
>IMO, the normative language should have applied to resolvers and been a 
>MUST. The application directive should either have been non-normative 
>or should have been MAY, providing guidance for developers of 
>applications where the risk of users accidentally providing a .onion 
>name is high (or at least moderate). Unfortunately, the horse has 
>already bolted. We could prepare an erratum, but Mark has suggested 
>that the value of that would not be very high.
>
>Frankly, I think the main thing we get out of this is a learning 
>experience. This is why RFC authors need to restrict their normative 
>language to things that can be enforced/detected by compliant 
>implementations. Any other use of normative language is just to make 
>the author feel better, rather than something that will actually get 
>done. It’s incredibly tempting to have broad-scoped unenforceable 
>normative directives: I seem to recall Martin shooting down a number of 
>them over the course of the writing of RFC 7540. I’m now personally 
>much happier with why we shouldn’t.
>
>Cory
>