Pardon me replying to two at once...
> On Aug 19, 2015, at 18:34, Seth David Schoen <schoen@xxxxxxx> wrote:
>
> [...]
> Right now, the industry allows .onion certs temporarily, but only EV
> certs, not DV certs (the kind that Let's Encrypt is going to issue),
> and the approval to issue them under the current compromise is going
> to expire
...or perhaps not...
> It's seemed like the efforts at IETF to reserve specific "peer-to-peer
> names" would be an important step in making it possible for CAs to issue
> certs for these names permanently. These efforts appeared to get somewhat
> bogged down at the last IETF meeting.
Hi, I'm Alec, and I am co-author of the Onion RFC draft with Jacob Appelbaum.
Reports of the bogging-down have been greatly exaggerated, and I wish people would stop repeating them.
The status of the Onion RFC draft is viewable at:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/
...and this afternoon I created some amendments to the draft to address IETF and IANA concerns, and have circulated them amongst the team (me, Jake, Mark) to see if I've goofed.
We will merge them, soon, in good time for the next review.
In the most recent review IANA in particular were very helpful, offering to rewrite some of their stuff in order to make it abundantly clear to CA/B-Forum that:
1) onion will be a special case
2) onion should never be delegated
3) but nonetheless SSL certificates should be issued for it
...which proactively addresses a concern from a few months back re: whether CA/B-Forum would nitpick a "Special Use" designation.
TL;DR - we are not past the finish line yet, and there is work to be done and challenge, but we're not down nor are we out.
Deadline is November 1st, as explained at length, here: https://www.ietf.org/mail-archive/web/dnsop/current/msg14065.html
> (I'm hoping to write something on the EFF site about this issue, which
> may have kind of far-reaching consequences.)
Good. Please avoid repeating the doom-and-gloom stuff that I've seen elsewhere, it distracts from the discussion to have to expend time correcting folk on Twitter.
> Anyway, I would encourage anyone who wants to work on this issue to get
> in touch with Christian Grothoff, the lead author of the P2P Names draft,
> and ask what the status is and how to help out.
The P2P Names draft is not relevant for ".onion" registration; for other Tor-related names such as ".exit", and other services such as ".i2p" it is still relevant.
> Theoretically the Tor Browser could come up with a different optional
> mechanism for ensuring the integrity of TLS connections to hidden services
> (based on the idea that virtually everyone who tries to use the hidden
> services is using the Tor Browser code). I don't know whether the Tor
> Browser developers currently think this is a worthwhile path. I can
> think of arguments against it -- in particular, the next generation hidden
> services design will provide much better cryptographic security than the
> current HS mechanism does, so maybe it should just be a higher priority
> to get that rolled out, rather than trying to make up new mechanisms to
> help people use TLS on hidden services.
I would recommend against giving up the pursuit of HTTPS certificates on Onion sites.
I explained some of this at https://lists.torproject.org/pipermail/tor-talk/2015-August/038712.html as follows:
Alec wrote:
>> The reason [ for pursuing SSL ] is simply that HTTP and HTTPS have diverged (and are apparently likely to diverge further?) in how they treat (eg:) secure cookies, and rolling a custom version of our codebase to know and understand that âHTTP over Onionâ will/may/will-not have features like referrer-scrubbing or CORS in a HTTPS-sympathetic manner (whilst the scheme in the request still *says* that it arrived over HTTP) would be complex. I personally feel that to expect more common codebases such as Wordpress or Drupal to special-case Onion addresses would be presumptuous, be unlikely, add cost, and inhibit Onion adoption.
Not creating barriers to wider onion adoption seems like a good idea to me.
Giving TorBrowserBundle special powers to make secure connections to Onion sites, thereby making (say) "stunnel" or "wget" ineffective for OnionSites, seems also to be a bad idea for adoption.
Conversely: Mozilla are going to start gating some of their features to be SSL-only: https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
Thus: making SSL work *somehow* - with privacy preservation where relevant - on onion sites, appears to be the path to greatest onion adoption.
> elrippo writes:
>
>> Hy,
>> i don't think letsencrypt will work on a HS because letsencrypt checks [1] if the domain you type in, is registered.
>> So for example on a clearnet IP which has a registered domain at mydomain.com called myserver.tld, letsencrypt
>> makes a DNS check for this clearnet IP and gets the awnser, that this clearnet IP has a registeres domain called
>> myserver.tld on mydomain.com.
>>
>> How should letsencrypt do this on a HS?
>
> If the CA/Browser Forum agreed that it was proper to do this, we could
> create a special case for requests that include a .onion name to use
> a different (non-DNS) resolution mechanism, recognizing "that DNS is
> not the only name resolution protocol on the Internet", as Christian
> Grothoff put it.
...etc.
For organisations which can arrange to register a EV certificate - companies, etc - once the ".onion" domain is formalised it will be possible to get a EV certificate created for an Onion address by using the process documented at https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/
Seth is precisely correct, however, that there is no means (yet) for individuals to register .Onion addresses for certificates, let alone anonymously.
I had discussions with some people in CA/B-Forum a few weeks ago, and there may be a way to pursue these ("IV Certificates" - see https://wiki.mozilla.org/CA:Glossary for details) - and assuming the .onion registration completes smoothly, I think that would be a good path to pursue.
> In a way, the special-casing is what makes some folks in the CA/Browser
> Forum nervous right now: if there's no "official" notion of the meaning
> of some names, how can CAs know which names should use which resolution
> mechanisms? (For example, maybe some CAs have heard that they should
> treat .onion specially, but others haven't.) If they're unsure which
> mechanisms to use, how can they know that the interpretation they give
> to the names will be the same as end-users
Very true, it's complicated.
Fortunately the light at the end of the tunnel, for once, is not an oncoming train.
- alec
--
Alec Muffett
Security Infrastructure
Facebook Engineering
London
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk