[cabfpub] Personal Certificates for ".onion"

Ryan Sleevi sleevi at google.com
Tue Nov 10 05:51:25 UTC 2015 

Forwarding on behalf of Paul

On Mon, Nov 9, 2015 at 9:28 PM, Paul Syverson <paul.syverson at nrl.navy.mil>
wrote:

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

More information about the Public mailing list