Re: Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-U

On 16 Jul 2015, at 0:40, Joe Hildebrand wrote:

> On 15 Jul 2015, at 19:18, Patrik Fältström wrote:
>
> > True, but if we look at the chat protocols, IETF could not agree on which 
> > one of three different protocols should move forward. Then XMPP came and, 
> > well, was developed elsewhere and basically "won".
> I do want to point out that we ceded change control over XMPP to the IETF, 
> and the XMPP working group made some fundamental changes to the protocol, 
> including start-TLS, stringprep, SASL, a new error name scheme, version 
> numbering, etc.
Exactly. Sorry for not being clear.

> A similar approach was used for SPDY morphing into HTTP/2.
>
> I don't see any way that these protocol development efforts can be used as 
> precedent for this draft.  If the TOR folks wanted to go through the process 
> to standardize their protocols, we could think about the architecture we 
> wanted for their identifiers and think about ways to avoid a special-use name.
Maybe, maybe not. Exactly how that would happen, and how, is of course unknown.

My point was that we do have many things that have first been "invented" 
outside of IETF and then brought to IETF intention and incorporated as the more 
successful IETF deliverables and responsibilities.

And for THAT I think XMPP is a good example.

> In the meantime, I have a specific technical objection to this draft, section 
> 2:
>
> > 2.  Application Software: 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'm skeptical that this SHOULD NOT will have any effect on any application 
> other than some small number of popular web browsers. There are a LOT of 
> non-web-browser applications in the world that do DNS lookups, and almost 
> none of them will ever find out that they are leaking information because of 
> this SHOULD NOT.
>
> As such, I suggest that this doc does not provide an adequate technical or 
> market-based mechanism that will achieve its stated goal.
   Patrik

signature.asc
Description: OpenPGP digital signature