<div dir="ltr">Forwarding on behalf of Paul</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 9:28 PM, Paul Syverson <span dir="ltr"><<a href="mailto:paul.syverson@nrl.navy.mil" target="_blank">paul.syverson@nrl.navy.mil</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ryan et al.,<br>
<br>
Apologies for breaking the thread by grabbing this message<br>
from the list's webpage (and for any other improprieties).<br>
I just joined this forum.<br>
<br>
While I appreciate the additional protections afforded by EV certs, I<br>
cannot find any validity in the arguments underlying the<br>
considerations you raise against DV certs for onionsites at all. I am<br>
sorry if I misunderstand something.<br>
<br>
By your criteria, confirmation of ownership or control of an onion<br>
domain according to the BR is cryptographically stronger than<br>
validation of registered domains.<br>
<br>
First, Tor is transitioning to SHA-256 and ed25519.  This has already<br>
been incorporated in alpha releases over the last c. half year. And<br>
there are many existing sites with DV certs still supporting RSA<br>
1024. So this is a temporary issue and one that would hardly be unique<br>
to onionsites.<br>
<br>
But more importantly, according to the currently published BR from<br>
<a href="http://cabforum.org" rel="noreferrer" target="_blank">cabforum.org</a> (1.3.0), checks for DV Cert authorization validation<br>
include "Having the Applicant demonstrate practical control over the<br>
FQDN by making an agreed‐upon change to information found on an online<br>
Web page identified by a uniform resource identifier containing the<br>
FQDN".<br>
<br>
Until transitions to SHA-256 and ed25519 are complete, an applicant<br>
for a .onion domain demonstrating practical control over that .onion<br>
address by this means would be protected by the self-authentication of<br>
the .onion address provided by the use of SHA-1 and RSA 1024.<br>
Whatever cryptographic weaknesses these may have, they are still far<br>
stronger than what an applicant for a registered domain accessed via<br>
unencrypted HTTP would be demonstrating.  (The Sept 10 draft revisions<br>
would not substantively change this observation.)<br>
<br>
And the argument from policing domain content seems a complete red<br>
herring.  Regardless of whether we agree with CA policing of<br>
subscriber's content or not, a CA unhappy with the content of an<br>
onionsite could revoke its certificate the same as they could for a<br>
registered domain for which they issued a certificate.<br>
<br>
Sincerely,<br>
Paul Syverson<br>
<br>
<br>
> [cabfpub] Personal Certificates for ".onion"<br>
> Ryan Sleevi sleevi at <a href="http://google.com" rel="noreferrer" target="_blank">google.com</a><br>
> Fri Nov 6 08:49:55 MST 2015<br>
><br>
>     Previous message: [cabfpub] Personal Certificates for ".onion"<br>
>     Next message: [cabfpub] Microsoft Proposed Updates to the SHA-1 Deprecation Timeline<br>
>     Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]<br>
<div><div class="h5">><br>
> Alec,<br>
><br>
> Various design and security considerations went in to the choice of<br>
> proposing EV for .onion. It wasn't necessarily meant to be the only way to<br>
> obtain HTTPS certificates for .onion domains, but as a means of assuring<br>
> (CAs, relying public) the balance of risks.<br>
><br>
> While not fundamentally opposed to exposing .onion for all (including DV),<br>
> here's a set of considerations that went in to the design and discussion:<br>
><br>
> - At Google, we were (and are) concerned with the cryptographic strength of<br>
> the .onion naming scheme, which employs both SHA-1 and RSA-1024. While only<br>
> the TOR authors can properly mitigate these attacks on a long-term basis,<br>
> the TOR Service Descriptor extension, combined with Certificate<br>
> Transparency, can at least shed light onto these attacks, since if the SD<br>
> differs-but-still-validates, then it's proof of an attack on SHA-1, and if<br>
> an unauthorized-but-valid cert appears in the CT logs, then it's proof of a<br>
> factoring attack on SHA-1. If allowed for any other types of certs, at<br>
> present, then these mitigations would not necessarily be viable.<br>
><br>
> - Related to that first point, the choice of EV discourages attackers<br>
> making such cryptographic attacks against sites operating .onion sites, as<br>
> it requires some form of identity validation of who the attacker is, even<br>
> if they have the cryptographic resources to mount such an attack. The goal<br>
> of supporting those without linking real-world identities (such as via<br>
> Richochet) is admirable and entirely understandable within the goals of<br>
> TOR, yet it also significantly increases the risk for those who presently<br>
> have .onion certificates, as it would be easier and viable for attacks<br>
> against them to remain unattributed. I don't mean to suggest that EV is<br>
> perfect at a defense against this, but, and especially combined with the CT<br>
> requirement, subversion of a CA's process for issuing an EV cert would be a<br>
> serious blow to the credibility and trust of that CA, and potentially lead<br>
> to it becoming untrusted.<br>
><br>
> - While this is a position that we (Google) generally disagree with, many<br>
> CAs feel that it should be their responsibility to police subscriber's<br>
> content and revoke certificates whose content they (or their governments)<br>
> disagree with. In general, and thankfully, this has primarily been limited<br>
> to malware and phishing sites. Since CAs view this as a guarantee being<br>
> offered by SSL (that the site is 'safe', for some nuanced definition of<br>
> 'safe'), allowing a wild world of unattributable certificates is<br>
> challenging to them. Note that some of these CAs have opposed DV at all, or<br>
> have looked for means to make DV non-desirable (such as through<br>
> restrictions on wildcards, shortened validity periods, or increased<br>
> requirements). All of this is captured in past minutes and discussions of<br>
> the Forum, and while I suspect there will be some disagreement on the<br>
> 'intent', the effects of such proposals are clear. Because of this concern,<br>
> it's likely that .onion certificates for anything less than<br>
> strongly-validated corporate identities will be opposed on the principle of<br>
> 'protect the users', an unfortunate mismatch for the guarantees that<br>
> SSL/TLS is meant to provide, but alas, a deeply held belief for some.<br>
><br>
> So in contemplating a solution of how to make HTTPS for .onion domains more<br>
> accessible - an entirely reasonable and extremely worthwhile goal - these<br>
> concerns must be taken into consideration and balanced. I don't believe<br>
> that an AV (I'm surprised to see that term; it's not in wide use) or IV<br>
> cert may necessarily or reasonably help balance those concerns, but<br>
> hopefully it provides further insight into the considerations and thoughts<br>
> behind the current support, so that yourself or others might be able to<br>
> provide a solution to thread those needles.<br>
><br>
</div></div><span class="">> On Fri, Nov 6, 2015 at 7:24 AM, Ryan Sleevi <sleevi at <a href="http://google.com" rel="noreferrer" target="_blank">google.com</a>> wrote:<br>
><br>
> > Forward on behalf of Alec<br>
> ><br>
> > ---------- Forwarded message ----------<br>
</span><div><div class="h5">> > From: Alec Muffett <alec.muffett at <a href="http://gmail.com" rel="noreferrer" target="_blank">gmail.com</a>><br>
> > Date: Fri, Nov 6, 2015 at 7:20 AM<br>
> ><br>
> > Hi CA/Browser Forum!<br>
> ><br>
> > I'm a software engineer and one of the authors of RFC 7686[0]; since 2001<br>
> > I have maintained a personal blog[1] and it's overdue for a complete<br>
> > software refresh. I want to take advantage of Let's Encrypt[2] to provide<br>
> > normal HTTPS certificates for the blog, and I want a 100% HTTPS deployment<br>
> > when I am done.<br>
> ><br>
> > I intend also to provide my blog with an Onion Address, thus my question:<br>
> ><br>
> > On my blog I do not represent a company - I act purely as an individual; I<br>
> > expect to easily get a "normal" domain-related certificate from Let's<br>
> > Encrypt, but as an individual I will not be able to get an EV certificate<br>
> > for my Onion Site as mandated by CA/B Forum Ballot 144[3].<br>
> ><br>
> > This situation inhibits me from protecting my personal blog's Onion Site<br>
> > with some form of Onion HTTPS certificate.<br>
> ><br>
> > It further discriminates against my choice of software deployment as an<br>
> > individual.<br>
> ><br>
> > Perhaps I could run my blog as HTTP-over-Onion and HTTPS-over-Internet,<br>
> > but this breaks my goal of a 100% HTTPS deployment. Clients of my Onion<br>
> > Site would not have access to HTTPS-only "Secure" cookies and other<br>
> > functionality which browsers today (or will soon) restrict to HTTPS[4]<br>
> > sites, e.g. Camera & Microphone access. This would be an undesirable lack<br>
> > of consistency.<br>
> ><br>
> > It is not viable to hack the Tor Browser to support an "Onion-only" CA,<br>
> > because only some portion of Tor traffic uses the Tor Browser; non-browser<br>
> > apps which use Tor would not be able take advantage of such a kludge, and<br>
> > thereby would not see the benefit of SSL.<br>
> ><br>
> > In any case, ".onion" is now an official special-use TLD, and therefore<br>
> > should be supported by official means.<br>
> ><br>
> > After a hint from Ryan Sleevi - plus referring to the Mozilla CA<br>
> > glossary[5] - I did some research and think that I need either an AV<br>
> > (address validation) or an IV (individual validation) SSL Certificate for<br>
> > my personal blog's Onion Site.<br>
> ><br>
> > Discussing likely use cases with Runa Sandvik[6], we believe that people<br>
> > who use Tor desire (at least) all of privacy, anonymity and integrity. The<br>
> > option that seems most sympathetic to all of these requirements is the AV<br>
> > (address validation) certificate. An AV certificate would provide an Onion<br>
> > Address with an SSL certificate (and thus a form of persistent identity)<br>
> > corresponding simply to an RFC822 email address. This would appear<br>
> > extremely well-suited to users of Onion-backed instant messenger software,<br>
> > such as Ricochet[7], especially those communicating without reference to<br>
> > "real world" identities.<br>
> ><br>
> > The alternative of an IV (individual validation) certificate appears<br>
> > closer to the goals of the EV certificate, being a more expensive "absolute<br>
> > identity" certificate that would (per the Glossary) require "a Driving<br>
> > License, Passport, or National Identity Card" to get. This would be useful<br>
> > for instances where people wish to publicly attest to ownership of what<br>
> > they write / blog / post / publish, but would be less useful e.g. for<br>
> > whistleblowers operating in repressive regimes.<br>
> ><br>
> > Frankly I see a need for both, and would be (for this case in point) happy<br>
> > to get one of either, but am also open to other alternatives which would<br>
> > not require me to register a company to bootstrap.<br>
> ><br>
> > So, finally, the question: how may I go about obtaining a suitable,<br>
> > personal, Onion-capable SSL Certificate for my blog, please?<br>
> ><br>
> > - Alec Muffett, London<br>
> ><br>
> ><br>
> > [0] <a href="https://tools.ietf.org/html/rfc7686" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc7686</a><br>
> > [1] <a href="http://dropsafe.crypticide.com/" rel="noreferrer" target="_blank">http://dropsafe.crypticide.com/</a><br>
> > [2] <a href="https://letsencrypt.org/howitworks/" rel="noreferrer" target="_blank">https://letsencrypt.org/howitworks/</a><br>
> > [3]<br>
> > <a href="https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/" rel="noreferrer" target="_blank">https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/</a><br>
> > [4]<br>
> > <a href="https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/" rel="noreferrer" target="_blank">https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/</a><br>
> > [5] <a href="https://wiki.mozilla.org/CA:Glossary" rel="noreferrer" target="_blank">https://wiki.mozilla.org/CA:Glossary</a><br>
> > [6] <a href="https://twitter.com/runasand/status/662341004373204993" rel="noreferrer" target="_blank">https://twitter.com/runasand/status/662341004373204993</a><br>
> > [7] <a href="https://ricochet.im/" rel="noreferrer" target="_blank">https://ricochet.im/</a><br>
> ><br>
> > [ This e-mail is also posted at<br>
> > <a href="http://dropsafe.crypticide.com/article/11697" rel="noreferrer" target="_blank">http://dropsafe.crypticide.com/article/11697</a> with additional context ]<br>
> > --<br>
> > <a href="http://dropsafe.crypticide.com/aboutalecm" rel="noreferrer" target="_blank">http://dropsafe.crypticide.com/aboutalecm</a><br>
> ><br>
> ><br>
> ><br>
</div></div>> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <a href="https://cabforum.org/pipermail/public/attachments/20151106/21e00eab/attachment-0001.html" rel="noreferrer" target="_blank">https://cabforum.org/pipermail/public/attachments/20151106/21e00eab/attachment-0001.html</a><br>
><br>
>     Previous message: [cabfpub] Personal Certificates for ".onion"<br>
>     Next message: [cabfpub] Microsoft Proposed Updates to the SHA-1 Deprecation Timeline<br>
>     Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]<br>
><br>
> More information about the Public mailing list<br>
><br>
</blockquote></div><br></div>