Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

[Alec Muffett]

> On Dec 10, 2015, at 03:08, George Michaelson  wrote:
> The 7 Layer model is a useful tool to talk about things, its not a rei-fied 
> thing. That said, apparent layer violations invite critique because they 
> inherently carry architectural consequence.

Very true. :-)

> I think the overloading of a (semantic space) name to have special properties 
> to take it out of the system is a case in point. Its an application through 
> session layer property: packets don't get sent using .onion labels in 
> source/destination fields.

Also true; most Tor Onion clients currently perceive Tor access as a (TCP) 
circuit to a SOCKS Proxy server which forwards packets onwards into a magic 
virtual network space where the layer-3-equivalent addresses are written 
strangely, indeed echoing the format of DNS addresses somewhat.

:-)

This is, of course, a complete heresy.  All "real" network engineers know that 
"real" network addresses are written as dotted-quads of decimal numbers, like 
"127.0.0.1", except for newer ones where "real" network addresses are written 
like "::1" a-la RFC5952

The browser manufacturers - brazen fools that they are - have gone FAR beyond 
these bounds, delved deep into namespaces where the only the foolish will 
tread, and will allow URIs to represent otherwise pure, unsullied network 
addresses in non-canonical but supposedly equivalent ways such as:

0177.0.0.1
0x7f.0.0.1
127.0.1
127.1
2130706433
01770001
0x7f01

- and (worse!) because of Tim Berners-Lee's lack of foresight in using a colon 
to separate host from port, the ideal, visual purity of an RFC5952 IPv6 address 
must therein be encumbered with brackets - [square brackets!] - when used in a 
URL!

HAS THIS INSANITY NOT GONE ON FOR TOO LONG ALREADY?

And now, this upstart "Onion" thing.  An 80-bit binary address which is encoded 
in base32?

WHY BASE32? SURELY THERE IS NO PRECEDENT FOR USING BASE32?

THE HUMAN EYEBALL ALREADY CANNOT COPE WITH THE VARIETY OF ENCODINGS WHICH ARE 
IN USE ON THE MODERN INTERNET!

And worse: They FLAGRANTLY SUFFIX this 80-bit binary blob (16 characters 
base32) with a string: ".onion" - to FLAUNT its difference!

What arrant perversion, the like of which we have not seen the like since X.25 
NUAs & NSAPs!

We should all march on the Tor office and Tell them!  We should tell them to 
convert to Dotted Quads like any RESPECTABLE protocol does, so they can use:

  http://122.152.229.227.20.102.54.239.123.210/

...which is FAR more obvious than "facebookcorewwwi.onion".

Specifically: it is far more obvious that users would not be able to survive 
with such addresses without using DNS.

Which is good, because that's what DNSOP loves to talk about.

- alec (`dd if=cheek of=tongue`) :-P

ps: Back when I was a young system administrator we had to remember addresses 
like 2342192001006995 and 130001.FTP.MAIL; kids today have got it easy.




> And the imposition on all the other layers to handle .onion specially, feels 
> (to me) a mortal wound. This, compared to the cost of taking syntactic limits 
> in the URI, and applying a lever there to wedge :tor: into the URI form, 
> denoting what you want to happen.
> 
> SOCKS is pretty much a shim. Its a clean layer impact. Its (to me) like 
> taking fopen() and replacing it by bzip2fopen() to get silent bz2 capability 
> in existing file I/O
> 
> On Thu, Dec 10, 2015 at 1:02 PM, John R Levine  > wrote:
> With onion you get a rather different thing that looks like an open
> TCP connection, a couple of levels up the protocol stack.
> 
> Strictly an Onion address yields you a _real_ TCP connection to your SOCKS 
> server, ...
> 
> It's certainly a virtual circuit, but it's not a TCP connection because the 
> endpoints aren't IP addresses.
> 
> The Onion addresses aren't making a "protocol switch", ...
> 
> Really, they are.  You can't do a DNS lookup on the address, there is no A or 
>  record with an IP address to which you can open a TCP connection.
> 
> Regards,
> John Levine, jo...@taugh.com , Taughannock Networks, 
> Trumansburg NY
> Please consider the environment before reading this e-mail.
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

[Alec Muffett]

Hiya!

> On Dec 5, 2015, at 03:44, John Levine  wrote:
> 
> With onion you get a rather different thing that looks like an open
> TCP connection, a couple of levels up the protocol stack.  So if the
> theory is that these special names are doing a protocol switch, it's
> not one switch, it's potentially a switch per name.  I suppose you
> could say there's yet another switch for test, example, and invalid
> that returns failure at whatever level of the stack you try.

Strictly an Onion address yields you a _real_ TCP connection to your SOCKS 
server, which tunnels that to the remote endpoint, connecting to a _real_ 
(though potentially synthesised) TCP Port Number at the server.

I find it simplest to think of Onion addresses as akin to using a SOCKS proxy 
to connect to an alternative Layer-3-address space, out on a VPN somewhere.

I find it hard to get particularly exercised about "Where does Tor sit in the 
7-Layer Model" when I haven't successfully yet answered that for SOCKS.  :-)

The Onion addresses aren't making a "protocol switch", they're merely 
constrained to TCP in the same way SOCKS is; and in much the same way that it 
is possible to ask a SOCKS proxy to connect you to 192.168.23.45 on port 22, it 
is equally possible to ask Tor to connect you to someonionaddress.onion on port 
22. Or 25, 80, 443, or whatever, so long as a listener has been configured on 
the other end.

-a



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

[Alec Muffett]

>> So it's IMO fine to say ".onion addresses are case-insensitive and
>> will comply with existing DNS limitations for label lengths (63) and
>> maximum fqdn lengths (253ish)".
>> Which contradicts draft-lewis-domain-names-00
> 
> 
> So - and not to be pointed - but in your email I reference, should I ignore 
> that for the sake of this document?  I mean what the message says seems to 
> contradict what you are quoting from Mathewson - which is fine - but this is 
> something unclear to me.


Yes, you should ignore that text.

Nick is the engineer at Tor who implements the relevant code.

In the following, he provides the following undertaking:

https://lists.torproject.org/pipermail/tor-dev/2015-August/009275.html 


> The examples in Proposal 224 are a mere 53 characters long leaving 10 to
> play with for padding-hyphens and possibly checksum characters.
>
> Nick: Is this likely to need to change? Or might there be a need to encode >
> 315 bits / 63 chars total?

I don't anticipate this changing.

If there were ever a need to encode more than that number of bits,
we'd add an extra label.

So, .onion addresses will stay within DNS bounds.  :-)

- alec



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

[Alec Muffett]

> On Sep 18, 2015, at 14:16, George Michaelson  wrote:
> 
> My private comment bears repeating in public.
> 
> DOMAIN names is about the property of domains. Domains are encompassing, 
> set-theory/venn-diagram style. A domain and a prefix are analogous concepts. 
> One is expressed syntactically somehow, the other is a mathematical property 
> of bounding in a number field but they have the same basic behaviour.
> 
> the UK domain order in coloured book mails obeyed this property: it just used 
> reverse semantics to the ARPA model.
> 
> .onion is *not* a domain name inside the .onion part: as I understand 
> it, the value is a hash, or other function which has no nesting properties 
> expressed syntactically.

Hi, my name's Alec, I work for Facebook and lead the engineering team for 
Facebook over Tor.

You are certainly correct that the label immediately left of ".onion" is a 
hash, and functions not unlike a layer-3 address; however, there may be other 
labels leftwards of the hash, under (to some extent) other administrative 
control.

The canonical example of this would be: www.facebookcorewwwi.onion 
 versus m.facebookcorei.onion versus… 
well, anything.you.like.sixteencharshash.onion.

With onion addressing it's all a matter of whether the layer 7 protocol honours 
the symbolic name that it has been given (eg: www.facebookcorewwwi.onion 
) and passes it to the server via metadata 
(eg: HTTP "Host:" header) rather than a delegated and differentiated address 
lookup.

I feel this may need clarification in your section on Tor addressing.  Perhaps 
it's not **really** domain-naming, but it **looks** much more like it.

Also, there is some information which requires correction:

According to an email message, ".onion" names may (in the future)
exceed the length limits of a label imposed on DNS domain names,
reaching 64, 80, or more bytes. [DNSOP1]

Per this e-mail:

https://www.ietf.org/mail-archive/web/ietf/current/msg94362.html 


...from Nick Mathewson at Tor, he says:
So it's IMO fine to say ".onion addresses are case-insensitive and
will comply with existing DNS limitations for label lengths (63) and
maximum fqdn lengths (253ish)".
Which contradicts draft-lewis-domain-names-00

Also, my name's not "Alex" :-)

- alec



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-onion-tld-01.txt

[Alec Muffett]

> On Sep 9, 2015, at 10:33, hellekin  wrote:
> Signed PGP part
> What would a DNS record about .onion in the root zone be used for?



I am advised by people I trust that "root zone database" > "root zone" and that 
this "means the DB that IANA uses to keep track of the root zone."

i.e.: the kind of stuff at 
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml
 


Good catch about the improper use of "TLD" in the document, thank you.  We'll 
ask the RFC editors to address that.

Thanks!

-a



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Jari Arkko's No Record on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

[Alec Muffett]

Hi Joe!


> On Sep 3, 2015, at 4:02 PM, Joe Abley  wrote:
> Pretty sure Joel was just referring to where the current documentation is 
> stored, not poking sticks at corporations.

Just in order to fight potential confusion at any point where it might flare 
up, lest other folk jump into this discussion and try running with it:

* The Tor specifications and code are on a Git repository owned by the Tor 
project, not at Github.  A simple DNS lookup will confirm this:

$ dig gitweb.torproject.org
; <<>> DiG 9.8.3-P1 <<>> gitweb.torproject.org
[…]
;; ANSWER SECTION:
gitweb.torproject.org.  3600IN  CNAME   vineale.torproject.org.
vineale.torproject.org. 3600IN  A   154.35.132.68

- so, any arguments which involve Github (Incorporated) are poorly grounded.

Continuing:


> There's nothing in 6761 section 5 that demands a reference to a stable 
> specification. The fact that there's any reference at all is a courtesy.


Per my previous e-mail, I would be happy to pluck out specifications, 
especially if they are blocking progress, because I see their inclusion as 
irrelevant to the matter of registering the special use domain name.

-a



—
Alec Muffett
Security Infrastructure
Facebook Engineering
London




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Jari Arkko's No Record on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

[Alec Muffett]

Come on, GitHub is a corporation, it has NOTHING to do with it.  Git is
a version control system.  An RFC falls to me exactly in the definition
of "the most current version of foo".  When something needs to be
amended, it is: that's what erratas and RFC updates and obsolescence are
for.  Please leave the strawman alone.


Hi Hellekin!

I am pretty sure that what was meant was something like:

As a Git Repository Page Hyperlink Within The Tor Project’s Website, they are 
simply "the most current version of The Onion Specification".

…and as I think that it is pretty obvious that that is what was meant, I 
therefore really fear that your reaction may be perceived as unconstructive.

Let’s fix that. :-)


Being, as I am, an IETF newbie, this does not strike me as a terrible problem, 
but clearly there is an issue here which animates several people, therefore it 
must be something important.

The references to “normative” and “downref” appear to be related to 
https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry and seems 
related to a desire to “freeze” the reason / address resolution specification 
for which the onion registration is being pursued.

Joel: please correct me if I have misapprehended this?

The thing is, I don’t think that “freezing” the address resolution 
specification for which the onion registration is being pursued, would be 
beneficial in the long term.

The onion names will be compliant with DNS syntax - that will be an invariant.

Their internal structure will evolve over the next few years, and importantly 
so, because security and software change at internet speeds.

The important thing is that:

1) “.onion” exists, and that
2) underneath it, resolution is in the hands of the current Tor software, and 
that
3) none of the above make the DNS barf.


Perhaps the solution is to somehow remove the tor address-resolution 
specification footnotes entirely?

- alec




> What the onion folks said to me was that they were working on
> creating stable, referenceable documents that explained how
> this should work.  I understand there is a time problem due to the
> certificate.  As a reviewer, I don't see how you can register
> without a stable reference for the meaning of the registration.
>

The referenced Tor documentation does not affect the reservation because
changes in that documentation won't affect the principles set forth in
the relation between Tor and DNS.  These are orthogonal matters.

==
hk


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Spencer Dawkins' No Objection on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

[Alec Muffett]

Hello Spencer!

> I do have one observation that I haven't seen anyone else touch on:
> 
> I thought .onion was tied closely to the TOR protocol, so I have no idea
> why the second sentence in this paragraph is here, or what it means, and
> neither the string "TOR" nor the string "onion" appear in RFC 7230, so
> chasing that reference didn't help.
> 
>   Like Top-Level Domain Names, .onion addresses can have an arbitrary
>   number of subdomain components.  This information is not meaningful
>   to the Tor protocol, but can be used in application protocols like
>   HTTP [RFC7230].
> 
> Am I just being dense the night before a telechat, and everyone else
> understands what this means and why it needs to be included in this
> document?


This matter has been discussed extensively elsewhere, and in response to 
feedback from that experience, this paragraph will be mildly amended to address 
matters of DNS syntax conformance:

   Like Top-Level Domain Names, .onion names can have an arbitrary
   number of subdomain components.  This information is not meaningful
   to the Tor protocol, but can be used in application protocols like
   HTTP [RFC7230].  Note that such names must conform to DNS name syntax
   (as defined in Section 3.5 of [RFC1034] and Section 2.1 of
   [RFC1123]), as they will still be exposed to DNS implementations.

What the first half of paragraph is attempting to express is outlined in my 
e-mail to the IETF Discuss list (and DNSOP)

https://www.ietf.org/mail-archive/web/dnsop/current/msg15084.html 
<https://www.ietf.org/mail-archive/web/dnsop/current/msg15084.html>


…where I write, at perhaps excessive length (and mildly edited for clarity):

>> Onion names are much closed to (say) dotted quads (or other layer-3 
>> addresses) than to domain names, albeit that to denote them there is the 
>> label ".onion" affixed in the place where one would expect to find a TLD.
>> 
>> Where the analogy between onion names and IP addresses breaks down is that 
>> the following is illegal (or, at least, has never been functionally viable):
>> 
>> http://www.192.168.0.1/ <http://www.192.168.0.1/>  (versus 
>> http://eliot.blogs.192.168.0.1/ <http://eliot.blogs.192.168.0.1/>)
>> 
>> ...whereas the following *is* viable:
>> 
>> https://www.facebookcorewwwi.onion/ <https://www.facebookcorewwwi.onion/>
>> 
>> In some hypothetical alternate universe where we were all using IP addresses 
>> rather than DNS to connect to endpoints, it might be cute to support 
>> . and let the "Host" header (and/or the HTTPS SNI) 
>> disambiguate the intent, though doubtless this would also lead to some kind 
>> of disaster.
>> 
>> In the Onion world, the canonical representation of an onion name is:
>> 
>> sixteencharlabel.onion (compare representations: 192.168.1.1, [::1], etc)
>> 
>> ...and in the outline we sketched of how Onions work, we sought to describe 
>> them properly in their role as layer-3 analogues, mechanically generated 
>> hashes of a randomly generated certificate, beyond human choice except for 
>> brute-force mining.
>> 
>> However, the Tor software has a party trick, that (as Richard has explained) 
>> given an "onion" label for surety, it's happy to parse-out the 
>> "sixteencharlabel" label and use that for connection establishment, ignoring 
>> any other labels leftwards of that, if any.
>> 
>> Of course using (say) "ssh" to connect to www.sixteencharlabel.onion 
>> <http://www.sixteencharlabel.onion/> will not be beneficial, because SSH 
>> supports neither "Host" header nor SNI; but a web browser using HTTP/S will 
>> pass a Host header, and thus we may effect virtual hosting over a single 
>> ".onion" names.

The really short summary of this is: Onion names are layer-3 analogues, but 
they look like domain names and may have trivial “subdomains” where the 
transport protocol would be happy to recognise, honour and differentiate 
subdomains via metadata transfer.

Does that help, please?

- alec

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Benoit Claise's No Objection on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

[Alec Muffett]

Hi Benoit!  Just to amplify a point that Hellekin has already made to the DNSOP 
list:

> If/Once [tor-rendezvous] is a normative reference, do we consider github
> as stable enough? What if that link disappears?

Mark Nottingham has an amended document - not submitted, but accruing 
amendments to address all the issues raised by IESG - at the following URL:

http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.txt 
<http://mnot.github.io/I-D/dnsop-onion-tld/draft-ietf-dnsop-onion-tld-01.txt>

…which he shared recently to this list, including a link to provide synoptic 
comparison of the existing draft and his amended copy.

In this new document you will see that - per recommendation - the relevant 
notes are being moved to a new, s5.1 “Normative” section, and (for clarity) the 
references to “gitweb.torproject.org" have been rewritten to reference the Tor 
Project’s specification site URI, spec.torproject.org 
<http://spec.torproject.org/>.

Any references to “gitweb.torproject.org” which you have seen in past (or 
currently) refer to a Tor Project internal Git repository, rather than the 
commercial Github company and its commercial offering.  The git software is 
open-source and widely instantiated. :-)

I hope this helps, and I shall be listening with interest to the call later 
today.  Thanks!

    - alec

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Alec Muffett]

Kevin,

> On Aug 10, 2015, at 3:54 PM, Darcy Kevin (FCA)  
> wrote:
> 
> In retrospect, the definition of the “http” and “https” schemes (i.e. RFC 
> 7230) should have probably enumerated clearly which name registries were 
> acceptable for those schemes, so that the following language from RFC 7320 (a 
> BCP) could be invoked against any attempt by an app – Onion or anyone else -- 
> to inject their own unique brand of “specialness” into the interpretation of 
> the Authority component of their URIs

To echo Mark’s rebuttal of this statement, I would like to ask what benefit 
would be served by doing so, please?

Thanks,

- alec

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Alec Muffett]

> On Aug 10, 2015, at 1:25 PM, Joe Hildebrand  wrote:
> 
> If the smiley means "they're already deployed, so we don't get to talk about 
> whether they're appropriate", then fine, but that's why a bunch of people are 
> complaining about the precedent this sets. If the smiley means "this is a 
> good protocol design that other people should follow", then I'm not sure we 
> have consensus on that.


I apologise that my personal opinion and cheery demeanour appears to be 
extrapolatable into a couple of contrasting strategic positional statements.

To put my personal opinion at greater and more clear length:

In the context of URI schemes, accessing a Tor onion site (currently) over HTTP 
or HTTPS is precisely *that* - a fetch of HTML or other content which a HTTP or 
HTTPS request might typically be used to access - without the client software 
needing to be adapted for Tor access at "Layer 7".

Such a fetch is functionally just a vanilla HTTP/S over an “alternate" 
transport, the latter generally enabled by a SOCKS proxy or a content-aware VPN.

Such fetches currently work, have done so for several years, and have been used 
by many, many thousands of users, possibly millions.

Similarly, ssh://user@someonionaddress.onion 
 is equally an extant and functional SSH 
request to someonionaddress.onion

Equally git://someonionaddress.onion/user/project-name.git 
 would not immediately 
strike me as needing to be forcibly changed to “onion-git://“ 
 simply because Git is invoked over an "alternate” 
transport with a “alternate” name resolution. It currently works, so why break 
it?

From this observation, my personal opinion of “the proper scheme for an HTTP/S 
fetch to an Onion address" is something of a duck-test:

TEST: if a fetch looks like HTTP/S and quacks like HTTP/S, then I think that it 
should likely be given a HTTP/S scheme.

Conversely: it’s arguable that schemes like “daap” or “rtsp” are also 
“HTTP-based”, and that *they* have special schemes, so perhaps fetches from 
Onion-addresses should “have special schemes” too?

I can sympathise with this argument.  It makes logical sense.

I personally differentiate and resolve this argument in terms of intent, and in 
terms of client and server-software.

“rtsp://” for instance is used for streaming, and requires magic, RTSP-specific 
headers, and the frontend is something like VLC or iTunes, and the backend 
requires a special streaming stack.

To me, this smells of specialism.

Equally: if iTunes incorporates a webview and fetches a bunch of web-content 
for human consumption, it likely uses a HTTP/S scheme to do so, rather than a 
specialist “ituneshttps://“ scheme.

This smells of specialist software trying to be a "general-purpose browser".

So, given these conditions:

- if the intent is largely to provide HTML+CSS content to human beings,
- if the client software is most likely a well-known browser (tor browser = 
firefox) operating in its normal mode
- …but not necessarily or exclusively a browser…
- and if the server software is something like Apache + {Wordpress, Drupal, a 
bunch of static HTML}

…then under these conditions, again, I apply the duck test. I feel that such 
fetches are HTTP/S and should have that scheme.

Hence why I feel that the extant, vanilla HTTP/S schemes are most appropriate 
for fetching browser content from onion addresses.

The other matters, regarding domain name resolution and generic URI syntax, I 
have already covered at some length.

   - a

*aside: using VLC to RTSP to an Onion address will work just fine when SOCKS 
(etc) is configured… etc...

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Alec Muffett]

Hi again, Ted!


> On Aug 10, 2015, at 11:42 AM, Ted Hardie  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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Alec Muffett]

On Aug 10, 2015, at 9:50 AM, Ted Hardie  wrote:
> 
> I believe that the registry we have currently defined doesn't do a great job 
> of capturing the actual needs here.  It doesn't define what the larger 
> namespace encompassing the DNS is or could be well, and it doesn't provide a 
> way to note the continuing evolution of the non-DNS resolution processes.  It 
> does a fine job with .example since that's fundamentally just a reservation, 
> but .onion is showing its warts.
> 
> I understand the urgency of the .onion case, but I suspect that we're going 
> to have to split it back out of the current registry once we have fixed the 
> problems with the registry itself.  I am wondering if there is a way forward 
> here where we permit the registration in the existing registry, but with a 
> note that it will likely move into either a different registry or an expanded 
> registry in the future.
> 



Hi Ted, thanks for the feedback.

I don’t see any question in the above which impinges upon the draft so much as 
being related to internal operations of IETF and/or DNSOP, but I’d like to 
reinforce that CA/B-Forum are apparently happy so long as “.onion” is part of 
the recognised global namespace.

The minutiae of which bucket that lives in is probably not an issue? (Tag: Mark 
Nottingham, Richard Barnes)

It strikes me that if labels “beneath” the .onion special domain name may in 
future exceed the bounds expected of DNS - but the root is acknowledged to have 
global legitimacy - then it’s all to the better that DNS software is aware of 
“.onion” and basically ignores it, which it the other intent of the draft.


In an e-mail elsewhere I recently noted:

>> A scan of section 3.2.2 of RFC3986 “Uniform Resource Identifier (URI): 
>> Generic Syntax” - I won’t claim to have read the whole thing - seems quite 
>> open to the existence of [namespaces other than DNS being used in URIs]:
>> 
>> A host identified by a registered name is a sequence of characters usually 
>> intended for lookup within a locally defined host or service name registry, 
>> though the URI's scheme-specific semantics may require that a specific 
>> registry (or fixed name table) be used instead. The most common name 
>> registry mechanism is the Domain Name System (DNS).
>> 
>> [...dns format description elided...]
>> 
>> 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. Instead, it delegates the issue of 
>> registered name syntax conformance to the operating system of each 
>> application performing URI resolution, and that operating system decides 
>> what it will allow for the purpose of host identification. A URI resolution 
>> implementation might use DNS, host tables, yellow pages, NetInfo, WINS, or 
>> any other system for lookup of registered names. However, a globally scoped 
>> naming system, such as DNS fully qualified domain names, is necessary for 
>> URIs intended to have global scope. URI producers should use names that 
>> conform to the DNS syntax, even when use of DNS is not immediately apparent, 
>> and should limit these names to no more than 255 characters in length.

Nothing appears in there about DNS’s (semantic) 63-character label lengths, 
instead the constraint defined is DNS “syntax” - arguably "strings of 
alnumhyphen separated by dots" - and an overall 255-character length limit.

Next-generation Onion Address Syntax has not yet been agreed, but the current 
plans exist within this syntax-and-255-limit definition, eg:
> a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion # first label 
> exceeds 63 characters, hypothetical illustration only
Existing Onion-Address Syntax (facebookcorewwwi.onion) is completely within 
existing DNS’s apparent semantics as well as syntax.

Of course, this is orthogonal to the matter of registries within registries 
which you raise above, but I feel it worth raising.

-a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Alec Muffett]

> On Aug 7, 2015, at 4:26 PM, Edward Lewis  wrote:

> … the documents I have access to do not give me a deep enough sense
> of, well, why the names are different from DNS domain names.  I presume
> they are from the email discussion, but what I am reading in the documents
> - and I stress "reading in the documents" meaning that might be the gap -
> doesn't give me enough background.

To address Edward’s implicit request for information - rather than to address 
his request for document pointers - I’d like to share that I sketched how onion 
addressing works in previous discussion at:

https://www.ietf.org/mail-archive/web/dnsop/current/msg13758.html 
<https://www.ietf.org/mail-archive/web/dnsop/current/msg13758.html>

…and am happy to answer questions to the best of my ability, or punt in the 
right direction.

Onion addresses may in future be >64 characters long, perhaps even >80, when 
new code rolls; the principles are likely invariant, however.

-a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Alec Muffett]

> 
> Yes, there is an HTTP Host header.  Yes, responses vary by the *value* but 
> not by the *structure*.  As far as Apache is concerned, for instance, I would 
> imagine it's doing a string compare without counting or considering dots.  By 
> discussing an arbitrary number of components, that paragraph implies that 
> HTTP cares about the *structure* of the name, when it does not (although some 
> implementations might kludge this with www.domain 
> <https://urldefense.proofpoint.com/v1/url?u=http://www.domain&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0A&m=A9kJsJTtp7y9FT7avJ3dH%2Biv4nQfZ6morew9jupKe6c%3D%0A&s=6e63e914f40b2ad82dba84208b2004762b55c9e266dc4e941a3b09a015a55c02>
>  = domain).
> 
> And I'll just hasten to add that now between you and Richard there are two 
> interpretations of what the text in the document means.  All I am suggesting 
> is a bit of clarity, please.


Hi Eliot,

I am one of the authors of this draft, and I would like to spell out the 
concern which was raised to us, and which we sought, with this paragraph to try 
and address.

Onion addresses are much closed to (say) dotted quads (or other layer-3 
addresses) than to domain names, albeit that to denote them there is the label 
".onion" affixed in the place where one would expect to find a TLD.

Where the analogy between onion addresses and IP addresses breaks down is that 
the following is illegal (or, at least, has never been functionally viable):

http://www.192.168.0.1/ <http://www.192.168.0.1/>  (versus 
http://eliot.blogs.192.168.0.1/ <http://eliot.blogs.192.168.0.1/>)

...whereas the following *is* viable:

https://www.facebookcorewwwi.onion/ <https://www.facebookcorewwwi.onion/>

In some hypothetical alternate universe where we were all using IP addresses 
rather than DNS to connect to endpoints, it might be cute to support 
. and let the "Host" header (and/or the HTTPS SNI) 
disambiguate the intent, though doubtless this would also lead to some kind of 
disaster.

In the Onion world, the canonical representation of an onion address is:

sixteencharlabel.onion (compare representations: 192.168.1.1, [::1], etc)

...and in the outline we sketched of how Onions work, we sought to describe 
them properly in their role as layer-3 analogues, mechanically generated hashes 
of a randomly generated certificate, beyond human choice except for brute-force 
mining.

However, the Tor software has a party trick, that (as Richard has explained) 
given an "onion" label for surety, it's happy to parse-out the 
"sixteencharlabel" label and use that for connection establishment, ignoring 
any other labels leftwards of that, if any.

Of course using (say) "ssh" to connect to www.sixteencharlabel.onion 
<http://www.sixteencharlabel.onion/> will not be beneficial, because SSH 
supports neither "Host" header nor SNI; but a web browser using HTTP/S will 
pass a Host header, and thus we may effect virtual hosting over a single 
".onion" address.

In pursuit of "clarity", having had this explained, I would welcome a better 
and more succinct phrasing, if you can offer one and yet not bury the reader in 
unnecessary detail, or in technical detail which might become inaccurate as 
implementations improve whilst the outline remains largely unchanged.


-a

--
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Alec Muffett]

> On May 21, 2015, at 4:41 AM, John Levine  wrote:
> 
> I share the concerns about calling .onion a TLD, but I think that's
> easily fixable by calling it something like a special purpose
> namespace, then going through the document and changing it where
> appropriate.

Not to complicate matters, but CA/B-Forum are saying the following:

https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/ 


> 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion 
> is in the right-most label of the Domain Name with a validity period longer 
> than 15 months. Despite Section 9.2.1 of the Baseline Requirements 
> deprecating the use of Internal Names, a CA MAY issue a Certificate 
> containing an .onion name with an expiration date later than 1 November 2015 
> after (and only if) .onion is officially recognized by the IESG as a reserved 
> TLD.

- my emphasis.

It would be a shame for them to nitpick the rules because "special purpose 
namespace" != "TLD"?

- Alec



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A comparison of IANA Considerations for .onion

[Alec Muffett]

> On May 12, 2015, at 7:44 AM, hellekin  wrote:
> 
> *** So in my understanding of the scope boundaries of RFC6761 IANA
> considerations, which seems to be the main difference between our drafts
> and our respective positions, the former is "an application", while the
> latter bundles "an application" and "a name resolution API or library".

Being a SOCKS-based service, of course, any SOCKS-enabled client can talk to 
Onion-space; including SSH, for instance.

-a



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A comparison of IANA Considerations for .onion

[Alec Muffett]

1. the users considerations pretend that users must use onion-aware
software in order to access Onionspace, but I assert that you and I can
use an ordinary Web browser, type in a .onion address, and access the
requested service.  Not only OnionTLD conflicts with P2PNames on that
point, it also confuses users' awareness and application software
responsibility (and possibly the scope of IANA Considerations' first
question).

I've asked about this issue several times, and I keep getting
different answers.  What isn't clear to me is whether there is
somewhere in the user's stack -- maybe it's the resolver, maybe it's
the application, whatever -- that knows that onion is special and
therefore shouldn't be looked up in the public DNS.  I assume there
has to be _somewhere_ that is special, or the alternative resolution
obviously wouldn't work.  I think that needs to be indicated
somewhere, because this fact is what makes onion a candidate under
6761, I think.

To put this to bed for Andrew’s benefit, I have uploaded a picture at:

http://i.imgur.com/tvXrD8N.png

The top is standard Firefox (for clarity it has also a BBC News tab open)

The bottom is Tor Browser, which is Firefox hardwired to a Tor SOCKS daemon 
that performs resolution.

On the Tor-enabled browser, you have access to extra sites in the “.onion” TLD, 
as illustrated.

For clarity of my terminology, I “used" both browsers in the same way: pasted 
the URL “https://www.facebookcorewwwi.onion/“ into both, hit “return”, clicked 
the mouse, etc, the same way I would “use” most browsers.

They are the same core codebase - Firefox - after all.

One of them - the Tor Browser - is using a SOCKS daemon which knows that 
“.onion” is special and shouldn’t be looked up in the public DNS.

The other has received NXDOMAIN from DNS.

I believe that this demonstrates the condition you were looking for?

The Tor browser also has special modifications (e.g.: plugins elided, features 
tweaked) to attempt to inhibit traffic ever hitting the internet except via the 
Tor SOCKS daemon, although these are more for privacy and consistency than for 
access.

- alec

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A comparison of IANA Considerations for .onion

[Alec Muffett]

Hi Hellekin!

 >Since Alec Muffett seems to have better things to do

I'm sorry if you've been waiting for my input - I am not the primary
author of the document; Jacob Appelbaum's name is in the document's
title for a good reason, and my involvement has been one of tuning a
few paragraphs, providing some wordsmithing, and cheerleading loudly.

Jake is - as I am sure you are aware - working for Tor, and is a busy
guy (last I heard was off in China doing something amazing) hence I
mailed out the latest draft when there was in extended (and ongoing)
lull in the desire for anyone on our editorial maillist to tweak it.

I'll do my best to respond to your points, albeit Jake and other
(wiser?) heads may have additional insights that I may miss by dint of
this being dropped on me at 10pm the night before the big phone call
to discuss such matters.

On that basis, you'll also please forgive me excising brevity.


 > 1. the users considerations pretend that users must use onion-aware
 >software in order to access Onionspace, but I assert that you and I
 >can use an ordinary Web browser, type in a .onion address, and
 >access the requested service.


If you are consciously running TAILS, I suppose so [ED: TAILS is a
Linux distribution which funnels almost all communication through Tor]
albeit that Tor would likely recommend against using a vanilla browser
in default configuration to access any part of Tor, let alone ".onion"
addresses, because risk of deanonymisation is too high with normal
browsers.  Hence the imprecations in favour of informed users,
reflecting Tor user-policy.

If you are not talking about running TAILS (or similar) then I must be
misapprehending what you mean by "can use an ordinary Web browser,
type in a .onion address, and access the requested service" because
your average browser - say Chrome - cannot access ".onion" without Tor
software help and some fiddly configuration.


 > 2. more importantly, where P2PNames imposes NXDOMAIN response to
 >authoritative name servers, OnionTLD makes it a soft requirement,
 >thus leaving the possibility for name servers to hijack Onionspace
 >without user consent nor awareness.


Yeah, we tossed that one back and forth a bit, and eventually if
slightly grudgingly went with the "SHOULD" on the basis that we wanted
the draft to be adopted more than we wanted to be thinking wishfully.


 > 3. this error is confirmed for DNS server operators, where OnionTLD
 >makes it a soft requirement not to override responses.


This might be an issue so long as your threat model includes blindly
unaware users who are typing ".onion" addresses into non-Tor-capable
browsers in the (presumably first-time) expectation that it will work,
and using resolver libraries which don't honour the imprecation that:

[draft-appelbaum-dnsop-onion-tld-01]
Resolvers that implement theTor protocol MUST either respond to
requests for .onion names by resolving them (see [tor-rendezvous]
[ED: A TOR-INTERNAL THING]) or by responding with NXDOMAIN.

...on a network infrastructure which is thoroughly pwned by a capable
bad actor.  Not totally impossible, I'll grant you, but threat models
which start from the assumption of a wholly ignorant userbase are
(joking aside) pretty flawed.

Continuing...

[DELETIA]


 >Since there is no central authority necessary or possible for
 >assigning .onion names, and those names correspond to cryptographic
 >keys, users need to be aware that they do not belong to regular DNS,
 >but are still global in their scope."
 >
 >OnionTLD contradicts this: "Users: human users are expected to
 >recognize .onion names as having different security properties, and
 >also being only available through software that is aware of onion
 >addresses."

Please explain the contradiction, I fail to see it?

[DELETIA]


 >This is the main conflicting point: OnionTLD does not recognize
 >.onion as special and allows Authoritative DNS servers to respond
 >for .onion ("SHOULD").  From the P2PNames perspective, this is
 >unacceptable, and a complete failure to address the privacy concerns
 >set forth by the draft.  If OnionTLD would be accepted in that form,
 >it would allow the root servers to capture leaked onion requests AND
 >RESPOND POSITIVELY FOR THEM !  *

There are entire papers about that.  Thank you for raising that point,
I wanted an excuse to post this URL to the DNSOP list:

https://petsymposium.org/2014/papers/Thomas.pdf

Measuring the Leakage of Onion at the Root - A measurement of
Tor’s .onion pseudo-top-level domain in the global domain name
system

...to help drive home the need for making ".onion" special.


As before, ignoring the potential for privacy-leakage of which site
you are seeking to connect to, this notion of "ZOMG TH

Re: [DNSOP] draft-appelbaum-dnsop-onion-tld-01 - seeking consideration and advice

[Alec Muffett]

Hi Warren!


> "instead of using the DNS infrastructure, .onion names functionally
> correspond to the identity of a given service, thereby combining
> location and authentication."
> to be very confusing.
> After a while I went and looked at the diff and saw that this used to be:
> ".onion names are hashes that correspond to the identity of a given service,"
> 
> I'm guessing that you changed this because of some comment? Anyway,
> this is in the introduction section, and so I think a little more, um,
> introductory text would be helpful. Perhaps saying that they are
> hashes of the key, and functionally correspond to 
> ?


That's very observant of you; the reason it was changed away from specifics of 
hashing-and-truncation are because the Tor project are currently in the process 
of overhauling hidden services, and it's entirely possible that the next 
mechanism may be substantially different - hence wanting to keep the 
description abstract and forestall arguments that the (eventual) RFC might be 
invalidated by evolution of technical details - the Tor Project will drive the 
implementation details, not the RFC.


> Also:
> "In this way, .onion names are "special" in the sense defined by
> [RFC6761] Section 3; they require hardware and software
> implementations to change their handling, ..."
> I'm not really sure if this is completely true -- I agree that
> software implementations would need to change, but I don't see how
> *hardware* implementations would need to change -- largely because I
> don't actually understand the concept of a hardware implementation of
> the DNS / .onion resolution stuff. Sure, some CPE runs *software* that
> does DNS, and some hardware accelerators run some DNS stuff in FPGAs,
> but I still don't see this a "hardware" implementation.
> I'd suggest just making that be:  "In this way, .onion names are
> "special" in the sense defined by [RFC6761] Section 3; they require
> implementations to change their handling, ..."


That's an interesting point which I shall bounce off Richard Barnes for my 
clarity; my reading of the text was any device - software (e.g.: Browser) or 
hardware (e.g.: printer, IPMI, wifi router, etc...) - which wants to resolve a 
".onion" name, must create ".onion" differently and eschew DNS in favour 
punting the connections to a Tor (SOCKS) server.  QED.


> Also:
> Throughout the document you state that thingies should return
> NXDOMAIN. Personally I think that this is a well enough known term
> that it is fine, but it isn't really defined (hoffman-terminology only
> sorta, kinda does). I'd think having a "should respond with NXDOMAIN
> (RCODE 3 - Name Error)" (or 'Non-Existent Domain') the first time it
> is used would head off future comments


Noted.  Thank you.  Thank you also for the extensive help.  :-)

- alec




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] draft-appelbaum-dnsop-onion-tld-01 - seeking consideration and advice

[Alec Muffett]

Hello All,

So a couple of days ago I posted draft-appelbaum-dnsop-onion-tld-01:

https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01 
<https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01>

Again, the diffs are minimal from -00:

https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-appelbaum-dnsop-onion-tld-01.txt
 
<https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-appelbaum-dnsop-onion-tld-01.txt>

…and I am cognizant of (planned, delayed) interim meetings to cover broader 
RFC6761 discussion points.  However I also have an elderly systems 
administrator’s eye towards extremely hard (and CABForum-sourced) deadlines and 
process, and I also hereby will admit my complete ignorant newbie-ness towards 
established procedure for DNSOP and RFC adoption.

“Everybody has to be a learner-driver at least once.”  :-)

So I would like to invite the community, please, to pass comment and 
consideration on draft-appelbaum-dnsop-onion-tld-01 which (if necessary) can be 
addressed in one last round of edits-to and review-of the document; and if 
someone would also kindly point me towards the process for seeking a “call to 
adoption”, I would be most grateful.

I hope to see all of the DNSOP processes - both established and ad-hoc - 
interlock in a graceful and well-oiled manner.

Many thanks and best wishes,

- alec

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] draft-appelbaum-dnsop-onion-tld-01 update (Was: Interim Meeting on Special Names and RFC 6761)

[Alec Muffett]

On Apr 14, 2015, at 1:02 PM, Warren Kumari  wrote:
> 
> Hopefully one that will for for those folk who a: live in Europe and /
> or b: will be at DNS-OARC and the DNS track at RIPE...
> 
> Seeing as Interims are supposed to be announced >=30 days in the
> future I'm guessing not the 14th of May…

Hi All,

Per this topic, I have uploaded v-01 of draft-appelbaum-dnsop-onion-tld; 
differences are viewable at:

http://www.ietf.org/rfcdiff?url1=draft-appelbaum-dnsop-onion-tld-00&url2=draft-appelbaum-dnsop-onion-tld-01
 
<http://www.ietf.org/rfcdiff?url1=draft-appelbaum-dnsop-onion-tld-00&url2=draft-appelbaum-dnsop-onion-tld-01>

…and the diff largely consists of some technical simplification, thanks & 
acknowledgements, and typos.

I would also like to take this opportunity to correct a timeline for the 
potential death of existing “.onion” TLD certificates in the instance that the 
“.onion" special use domain is not registered in the near-to-medium term; this 
correction arises from a misunderstanding on my part of the results of CA/B 
Forum Ballot 144, and is not a substantial error (off by one month) but I would 
like it to be clear for all interested parties.

  -a

== Summary ==

All “.onion” SSL certificates will be revoked if “.onion” is not approved as a 
special use TLD on/by November 1st 2015; if “.onion" is approved then the 
certificates will persist without action being required.

= Timeline =

== March 2014 ==

CA/B Forum approve Ballot 144, paving a route to “proper” SSL Certificates for 
Onion Sites

== Current Day Goes Here ==

Hello world.

== 1 May 2015 ==

All existing ".onion” SSL Certificates which were issued under the “local 
names” exception “must” be revoked by their issuer, the expectation being that 
the certificate holder will receive a new Ballot-144-compliant “EV” Onion 
certificate.  This is what i was not formerly clear regarding, and see below 
because...

== 1 October 2015 ==

The "Local Names” exception, under which SSL Onion certificates were originally 
issued, dies; this will doubly-kill all the Onion certificates, however the 
Ballot-144-compliant “EV” Onion certificates have until…

== 1 November 2015 ==

…which is the CA/B Forum “deadline” for IETF to approve “.onion” as a TLD; if 
“.onion” is not approved by this time then the certs will be “turned off” / 
killed by the certificate authorities.

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[Alec Muffett]

>Alec, would you care to explain 
>the differences on the IANA 
>considerations between this 
>draft and the P2PNames draft

Woo! I'm honoured, but I am a considerably less IANA-informed schmuck than you 
take me for. :-)

I've been heads-down in Tor and the wider Tor community for some time now, and 
I see the ".onion" TLD as something small and focused which is sensible and 
doable, and my grasp of the ramifications is that adoption of ".onion" as a 
special use domain name presents no obvious harm, quite a lot of good (and 
opportunity) plus might help shape a wider consideration. 

What happens/ed in consideration in other committees, I am not fit to speculate.

-a

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[Alec Muffett]

Hi Hellekin!

I would agree that leak avoidance is “a major” rather than “the prime”
point of having .onion reserved as a TLD.

There are many good reasons for reserving “.onion” as a TLD, including but
not limited to:

- avoiding leaks (above)

- not wasting resource on trying to resolve the “.onion” special use
domain name (flipside of above)

- SSL/TLS EV certificate issuance per CA/B Forum Ballot 144

- ...meaning that sites can adopt a “.onion” address without reworking
their HTTPS code

- ...and also that EV site attestation works, to the extent that that may
be valuable (eg: SecureDrop site for )

- generally putting “.onion” on an official footing / erasing doubt

Folk more creative than I can certainly add to this list, though as you
say privacy (esp: organisations watching for people doing errant onion
lookups) are a risk to the privacy of individual users!

- alec


On 3/24/15, 10:45 PM, "hellekin"  wrote:

>*** Well, although you're right as far as *applications* are concerned,
>this is still a big deal because humans are using these appplications,
>and that's the prime interest of having such a TLD reserved in the first
>place, that the DNS does not propagate any leak.  So I agree with your
>amendment, but not with the "not a big deal" statement, which completely
>ignores the fundamental privacy implications of such leaks to the DNS.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[Alec Muffett]

Hi Andrew,

If I understand your question correctly, you are asking whether in the
instance that a DNS server receives and caches a NXDOMAIN for some/all
.onion, whether that could impact software which uses Tor?

Software which uses Tor does so via a proxy which internally performs the
resolution of the target “.onion” address (or any website, via Tor) into a
TCP-like circuit which connects to the destination server.

Thus the situation should be that either:

a) the software in question is talking to a Tor proxy which acts as a
gateway to the Tor network (and to the rest of the internet-via-Tor) which
resolves ".onion” addresses meaningfully, or else:

b) the software in question is *not* talking to a Tor proxy, and therefore
cannot meaningfully resolve or communicate with onion addresses, nor use
the Tor network.

If the software is somehow both talking and bypassing the proxy, my sense
is that it would be the software's responsibility to deal with the
self-imposed complex situation in a sane manner; an example of this might
be http://en.wikipedia.org/wiki/Tor2web

-a


On 3/21/15, 11:12 PM, "Andrew Sullivan"  wrote:

>In section 4, 3-5, what if a "synthetic" NXDOMAIN gets generated and
>cached?  Will that have any effect on .onion resolution?  If this is
>explained in detail in some thing I've failed to follow, a simple
>reference would be enough.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[Alec Muffett]

Hi Ruben,

Perhaps you have some greater point in mind regarding this observation, could I 
ask you please to expand on it, so that I understand better what aspect is 
interesting you?

- alec

From: Rubens Kuhl mailto:rube...@nic.br>>
Date: Tuesday, March 17, 2015 at 7:44 PM
To: Alec Muffett mailto:al...@fb.com>>
Cc: dnsop mailto:dnsop@ietf.org>>
Subject: Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

The ballot explicitly calls .onion an specified non-internal name, so whether 
the IETF defines that as non-delegatable doesn't really seem to matter to CA/B 
Forum, does it ?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[Alec Muffett]

Hi Ruben,

As I think you’ll see from the document, in our seeking classification of 
“.onion” in the “special use domains registry” under the terms governing that 
space, I think it’s fair for me to say that NXDOMAIN is pretty much what we’re 
shooting for.

There are probably some edge cases to the argument which should be clarified by 
more experienced DNSOP hands than I - Richard? -  but overall I think we are in 
agreement regarding that aspect of the outcome.

As for the “alleged” nature of the time-sensitivity, may I please direct your 
attention to:

https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/

…specifically:

“Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose 
subjectAlternativeName extension or Subject commonName field contains a 
Reserved IP Address or Internal Name.”

…which I think would best be described as a “concrete” rather than “alleged” 
time sensitivity.

- alec


From: Rubens Kuhl mailto:rube...@nic.br>>
Date: Tuesday, March 17, 2015 at 7:15 PM
To: Alec Muffett mailto:al...@fb.com>>
Cc: dnsop mailto:dnsop@ietf.org>>
Subject: Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

.onion was already under consideration under other drafts, but now there is a 
request specifically for .onion alleging time sensitiveness. But on the 
TLD-level, the only possibility of it becoming a response different from 
NXDOMAIN is a possible new gTLD round, something that is many years in the 
future... so the point for a .onion-specific work instead of it becoming part 
of a larger effort still escapes me.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[Alec Muffett]

Hi Rubens!

On 3/17/15, 6:34 PM, "Rubens Kuhl"  wrote:

>> 
>And where in this ballot is there a need for explicit reserving of
>.onion, since CAs already know they shouldn't try using DNS in the
>process of verifying a .onion certificate ?

If I correctly understand the direction of your question, that is, in
fact, why this document is here for consideration.

Consideration by DNSOP is relevant to taking forward the matter of putting
“.onion” into the special use domains registry, per the previous e-mail by
Richard Barnes, as viewable at:
http://www.ietf.org/mail-archive/web/dnsop/current/msg13765.html

>I would rather consider them DV due to the nature of the proposed
>validation, but that's likely off-topic in DNSOP...

Indeed, I would agree that it is off topic for DNSOP, and I would also
note that CAB Forum consider the matter decided to their satisfaction, and
that they have voted and agreed the matter.

If review of their deliberations would interest you/others, may I please
direct your attention to the CABForum list and the thread at
https://cabforum.org/pipermail/public/2015-February/004922.html where the
ballot was approved, prior to voting.

- alec

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[Alec Muffett]

Rubens, allow me please to direct your attention to:



https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names
/

Aside: EV certificates are what will be issued for Onion addresses, even
wildcard onion address certificates, for reasons explained on the Ballot.

- alec


On 3/17/15, 5:30 PM, "Rubens Kuhl"  wrote:

>Considering .onion is a non-resolving TLD, how would a CA issue a
>certificate for a .onion name that they can't verify whether the
>requester is the administrator of that service ? DV certificates can use
>lots of mechanisms to verify that, but is one of them feasible for CAs to
>use ? 
>

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[Alec Muffett]

Before this discussion becomes derailed by discussion of the strategies of
the contents of other proposals, I would like to round this discussion
back to the matter of the draft-appelbaum-dnsop-onion-tld-00.txt document:

Christian’s response clearly distinguishes the separateness of Jake & my
document "draft-appelbaum-dnsop-onion-tld-00.txt” from his
“draft-grothoff-iesg-special-use-p2p-names”.

I believe this clearly answers the question that Paul Wouters raised in
his first response.  The two are separate enterprises.

In my previous e-mail I have outlined the goals of
“draft-appelbaum-dnsop-onion-tld-00.txt” and will happily address any
further questions.

May I please request approval to post to the list in order to respond to
any further questions? I am a newbie to DNSOP and am unsure whether,
having subscribed and responded to one submission confirmation, whether
this means my future posts will be automatically approved.  I guess that
I’m about to find out.

- alec

--
Alec Muffett
Security Infrastructure
Facebook Engineering
London

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[Alec Muffett]

Hi!

I’m Alec Muffett, I am the other author of this document.

I am a software engineer working at Facebook, and am the lead on the
Facebook over Tor project - https://facebookcorewwwi.onion/

I’ll do my best to answer as many of the extant questions as possible, so
far:


On 3/17/15, 1:14 AM, "Paul Wouters"  wrote:

>On Mon, 16 Mar 2015, Jacob Appelbaum wrote:
>> Subject: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
>
>Is this meant to replace or augment
>draft-grothoff-iesg-special-use-p2p-names ?


My understanding is that this is not meant to replace that document, but
instead that this document is a separate one.

Being as I am one of the authors of this document, I believe that my
opinion carries some weight in this matter.

The reason I am not more emphatic in this matter is that the question
as-phrased is essentially about *that* document, not this one, and I do
not speak for or on behalf of Christian Grothoff, author of that document.

Thus, I shall cc: Christian into this message, in case he wishes to
describe his perspective of that document with respect to this one.


>How does the certificate "dead line" affect (non-)DNS for .onion?

Permit me to quote Brad Hill:

Quote: "The end date for the internal names loophole* is October - all
public certs [which are issued] not for public namespaces MUST be revoked
at that point. CAs can continue to issue up to that time, but they all
must expire or be revoked on Oct 1, and no new ones issued. Those certs
are really extremely dangerous, and [Brad has] been working for NINE YEARS
now to make them go away. Can't happen soon enough.” 

The “facebookcorewwwi.onion” certificate (please feel free to examine the
SSL certificate issued by facebook.com for details) is currently issued
under a loophole that permits Subject Alt Names to contain "local” and
domain-names.

CA/B Forum have - as Brad hints above - planned to kill such, for some
time.

In Ballot 144, CA/B Forum approved process for formal issuance of SSL
certificates to ".onion” addresses, providing satisfactory means to
attribute ownership.

Note, though, Brad’s comment, "not for public namespaces”, ie: that
certificates will, after October 1st, only be issued for approved public
namespaces.

Thus: ".onion” needs to become a formally approved public namespace.

Hence this document: The goal is seek formal approval of “.onion” as a
TLD.  

I will defer to Richard Barnes and Mark Nottingham regards the larger
aspects of this process, but in passing note that Hellekin’s observation:

Quote: “we can also consider it a god-given gift for people who argued
against multiple TLDs in a single draft” 

…is precisely correct; this is a small, simple proposal for (we hope) a
small, simple change, in (ideally) prompt time.



>I have reviewed the document and I'm not sure what is intended? I think
>it is meant as advise to DNS implementors? I guess it is an attempt to
>reduce .onion leaks if those happen to hit the DNS infrastructure?

The goal is to seek formal approval of “.onion” as a TLD; as such, that
the larger DNS community understands the special nature of the onion
namespace is an important thing.

To paint a naive, thumbnail sketch of how “.onion” addresses work:

1) A user creates a RSA key, distinct from SSL or IPSec or any other form
of crypto
2) The user hashes the public key using a specific hash function.
3) The hash, being unfeasibly large, is truncated a bit and the resulting
bitstring rendered as a (currently) 16-character string
4) The resultant string has the word “.onion” appended to it, and the
whole serves as a layer-3-like endpoint in an encrypted peer-to-peer
mesh-type network “cloud”

All communications are protected by RSA under the key of the server which
someone is connecting to.

As is obvious, in this scheme there is no “root zone” for “.onion” and
there is no “directory” either; instead the “cloud” maintains a dynamic
set of mappings from Onion Address to IP Address, which (by design) change
at regular intervals to defeat various attacks.

People are expected to gather the onion address to which they are
connecting via other means, eg: advertising or social media.

By a process of mining arbitrary keys and experimentation, an onion
address which is semi-human-meaningful can be established in order to make
things easier for people, eg: blockchainbdgpzk.onion or
facebookcorewwwi.onion

However, to reinforce: there is no root zone, no centralised directory.
You can see elements of the underlying entropy of the hash in the “dgpzk”
of “blockchainbdgpzk.onion” - these are actually binary strings with a
hint of human readability, rather than “domain names”, and thus no
centralised repository is required since they can be accessed via
mechanical discovery, quite similar to “192.168.1.1” is accessed via ARP &
Routing.

But, again by analogy to IPv4, you can see the potential risk to