[cabfpub] Ballot 144 -.onion domains

[kirk_hall at trendmicro.com]

BR 11.5 High Risk Requests
The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.

High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria.

We won’t issue certs for microsoft.example.com, googleserver.example.com, etc., even though our customer owns example.com.  I think the same concerns would apply to .onion certs, for the same reason.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Thursday, February 12, 2015 6:44 PM
To: Kirk Hall (RD-US)
Cc: Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com); CABFPub (public at cabforum.org)
Subject: Re: [cabfpub] Ballot 144 -.onion domains



On Thu, Feb 12, 2015 at 6:33 PM, kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>> wrote:

In contrast, a .onion domain name will be displayed to Tor users, and could cause confusion.  Should we require CAs to follow the rules of BR 9.2.4g so that .onion domains that include meaningful names are verified?  Or better yet, not allow .onion domains to be meaningful (require them to be random only)?

How do you define meaningful? How do you define random? In quantifiable ways that can either be audited or inspected by third-parties (e.g. via Certificate Transparency)

facebookcorewwwi is a random name. That it has symbolic meaning in English is something that happens with any random system, given sufficient time.

Would these concerns go away if Item #5 was removed from the ballot (the automatic extension if IESG reserves)?

While I think this discussion is useful to a degree, I do have some concerns:

- Under the current provisions, anyone can issue for .onion, so this is by no means worse in any quantifiable way

- Under the current provisions, using a .onion with HTTP is objectively less secure than using a .onion name with HTTPS
  - A .onion name is based upon an RSA-1024 bit key, which is the only security protection in play here.
  - A .onion name is denied access to privacy-and-security enhancing technologies (due to browsers restricting access to features not delivered over secure transports)

- The concerns regarding 'spoofability' of a .onion name exist independent of any discussion in the Forum. That is, it is, at it's core, a TOR protocol "issue" (I'm not sure I would call it that, but for sake of discussion...)
  - Anyone using .onion names can create facebookwwwcore1.onion, given sufficient time and energy
  - DNS spoofing exists entirely in the Baseline Requirements (CAs are only required to document their procedures regarding high risk requests. They are not prohibited from issuing such phishy names, per 11.5 of the BR 1.2.3)
  - DNS spoofing exists entirely in the EV Guidelines (CAs are only required to inspect mixed-script domains, per 11.7.1 p2 of the EVG 1.5.2)

Nothing prohibits facebookcorewwwi.com<http://facebookcorewwwi.com> and facebookcorewww1.com<http://facebookcorewww1.com> from purchasing certificates, EV or DV, provided they demonstrate control over that namespace. Why would or should .onion be any different?

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150213/7f5bd98b/attachment-0003.html>