Delivery-Date: Wed, 19 Aug 2015 14:44:15 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id D78691E04AA;
	Wed, 19 Aug 2015 14:44:12 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 713EF366DB;
	Wed, 19 Aug 2015 18:44:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 0C8D23645B
 for <tor-talk@lists.torproject.org>; Wed, 19 Aug 2015 18:44:05 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id DGPCCZG9Lcgy for <tor-talk@lists.torproject.org>;
 Wed, 19 Aug 2015 18:44:04 +0000 (UTC)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com
 [67.231.145.42])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id C691A36428
 for <tor-talk@lists.torproject.org>; Wed, 19 Aug 2015 18:44:01 +0000 (UTC)
Received: from pps.filterd (m0044008 [127.0.0.1])
 by mx0a-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id t7JIekEc022346;
 Wed, 19 Aug 2015 11:43:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com;
 h=from : to : cc : subject :
 date : message-id : references : in-reply-to : content-type :
 mime-version; s=facebook; bh=CCig74/N9zlN88UNeYJEkt1aswd9Zi38MzTPpGEknDo=;
 b=JiczEY6f9HrKAULRQ4sMqw5kbce5uACh/4YZOglpdSx5UQ/k3GSMbB/LeETYfspo/CSK
 l+WZoT2Ypgo7Utlx6Ah1u+u6atntpS/dKin7KLx/x6lirHpdTQ9dG8Gy29qK6KtLo55B
 ghwo0BPuAbF6CQn9chjdptFvAYA4u1RAG7U= 
Received: from mail.thefacebook.com ([199.201.64.23])
 by mx0a-00082601.pphosted.com with ESMTP id 1wcwbyrdbb-2
 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
 Wed, 19 Aug 2015 11:43:54 -0700
Received: from PRN-MBX02-4.TheFacebook.com ([169.254.2.114]) by
 PRN-CHUB01.TheFacebook.com ([fe80::d5cc:849:f520:db6b%12]) with mapi id
 14.03.0195.001; Wed, 19 Aug 2015 11:43:54 -0700
From: Alec Muffett <alecm@fb.com>
To: "tor-talk@lists.torproject.org" <tor-talk@lists.torproject.org>
Thread-Topic: [tor-talk] Letsencrypt and Tor Hidden Services
Thread-Index: AQHQ2mueVdt/imG/5kOEsL0LatP4AJ4UCzYAgAATRoA=
Date: Wed, 19 Aug 2015 18:43:53 +0000
Message-ID: <B1166FAC-2BB1-4FFD-A391-5D7E2A5231F5@fb.com>
References: <55D45D3B.3070401@infosecurity.ch>
 <20150819173452.GT9483@mail2.eff.org>
In-Reply-To: <20150819173452.GT9483@mail2.eff.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.52.123]
MIME-Version: 1.0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,
 0.0.0000
 definitions=2015-08-19_08:2015-08-18,2015-08-19,1970-01-01 signatures=0
Subject: Re: [tor-talk] Letsencrypt and Tor Hidden Services
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3182306502758038303=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

--===============3182306502758038303==
Content-Language: en-US
Content-Type: multipart/signed;
	boundary="Apple-Mail=_E3FBE01B-FB4F-4668-8C06-B0DA0D810F05";
	protocol="application/pgp-signature"; micalg=pgp-sha512

--Apple-Mail=_E3FBE01B-FB4F-4668-8C06-B0DA0D810F05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Pardon me replying to two at once...


> On Aug 19, 2015, at 18:34, Seth David Schoen <schoen@eff.org> wrote:
>=20
> [...]
> 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 =E2=80=9CHTTP over Onion=E2=80=9D =
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:
>=20
>> 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.
>>=20
>> How should letsencrypt do this on a HS?
>=20
> 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-name=
s/

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


--Apple-Mail=_E3FBE01B-FB4F-4668-8C06-B0DA0D810F05
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV1M5oAAoJECldTB9TIAHG5soP/j3MK5HN6RbGultYVnEgNpNi
qnbhsIMgQJRgZ05lLlJgFJfG8f6Z5abY6gEqaSYtgL/CMcI/riLZfvyV2It1S3/N
to9k+EjXZht9cg/zIXCD4Nm6crsPt6weeY6iGsuV9bO/YQCrFfEIYSBRHb/pMuz5
NNK9+1ruWpByqhId/xtNxSvRsreJ4TxtSxlbLFOk8PeIBDsCbG+ohvIh/uU6TaKY
U2Rg1V3peGfQkqfLcvHOLmVliXJSDRXjLtXrddjt4sP00EVMWXJE3XFzHxZHLjvI
yf168tZo/HxOSHxg8ny2heCs5fnB3YFhlnuRiTuduIIvJ7TmlZdzN2knte+qcfyt
zZU27bv8YEfq/DOjBLY/rcEsLj3ui9NSq4DTykQB19B57t7UI0jEBwb/2YWg14io
SmOw4QtyEUnn2HYFJeXVfLj4j7eZfKNzs22GV8/1TL7F/l4xUoeFJ1b0NDBvci7k
rJ+CK8zOODhDFpc9KQaYmMZIdIV6eATJ3ZPJxlruQPvIqyyX3VbTjMKZth8R/J24
j5JMjmHSJk6/pqWVKkmw1gD6/DEoBALB4grTRgWrreoKIkpvL3tiUij8AixNJrES
8i+7bjyCYJteTr9FkoZha2DGpyCjjOAFJsytyZtgr4AJJccv7TfJH4QLshm2bQn0
vZjByUjIbDTJ7N+TfXnl
=zPeI
-----END PGP SIGNATURE-----

--Apple-Mail=_E3FBE01B-FB4F-4668-8C06-B0DA0D810F05--

--===============3182306502758038303==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

--===============3182306502758038303==--

