Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion S

Hi again, Ted!


> On Aug 10, 2015, at 11:42 AM, Ted Hardie 
> <ted(_dot_)ietf(_at_)gmail(_dot_)com> wrote:
> […]
> ​I think the Internet community needs to understand that a reservation in the 
> encompassing name space means that no gTLD with the same string will be 
> permitted in the DNS and understand who has the right specify the process by 
> which the names within .onion are minted and assigned.
I would agree, in fact I feel this was strongly thrashed-out in discussion of 
the draft.

> > > A scan of section 3.2.2 of RFC3986 “Uniform Resource Identifier (URI): 
> > > Generic Syntax”
> > > […]
> > > This specification does not mandate a particular registered name lookup 
> > > technology and therefore does not restrict the syntax of reg-name beyond 
> > > what is necessary for interoperability.
> ​This is a little bit more complicated than the above suggests, because a 
> specific URI scheme can describe in detail which elements of RFC3986 syntax 
> are expected within it.  See, for example, RFC 6068, Section 2 
> <https://urldefense.proofpoint.com/v1/url?u=http://tools.ietf.org/html/rfc6068%23page-3&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0A&m=oCCVXQHML7Wu9tLutu8gi0yjQy%2FYshsl6QPZDObXbt0%3D%0A&s=169bbca645c89ea6cb6b8e1f492f00233288a5afea42e886b71051a7e31cdb61>
>  for the syntax of the mailto: URI (which is fundamentally different from URI 
> schemes which use path elements in the way HTTP does). RFC 7595 
> <https://urldefense.proofpoint.com/v1/url?u=https://tools.ietf.org/html/rfc7595&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0A&m=oCCVXQHML7Wu9tLutu8gi0yjQy%2FYshsl6QPZDObXbt0%3D%0A&s=2902ce28be4aa8782a28349946b7aeba381329ac17f118c226111a2f7de618d1>
>  has some additional detail in the context of registrations.
Some Googling suggests that the http:// scheme is defined in RFC 2616, which - 
to summarise - again does not mandate DNS.

- Section 3.2.2 defines the host-name part in abstract regards TCP connections:
> identified resource is located at the server listening for TCP connections on 
> that port of that host
- Section 3.2.3 discusses string comparisons

- Section 15.3 discusses DNS spoofing and DNS caching, which is inapplicable

- Sections 5.2 and 14.23 discuss the Host header, the latter most specifically:
The Host field value MUST represent the naming authority of the origin server 
or gateway given by the original URL.
…again without reference to DNS.  Since the use of an Onion in a Host header 
would reflect the origin, I think this works.

So, by this analysis I think Onions in http (and by extension https) are fine.

Not to mention, appropriate. :-)

> In this case, I believe .onion names that intend to be carried in URI slots 
> that would also carry non-.onion names will either have to confirm that the 
> URI's scheme-specific part permits it or update the syntax to do so.
Exactly.  I believe that they do.

> ​I believe that it would be valuable to check the proposed syntax against the 
> individual schemes' scheme-specific-parts as part of the deliberations.
Where else would you suggest looking, please?

    -a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

signature.asc
Description: Message signed with OpenPGP using GPGMail