[cabfpub] Ballot 144 -.onion domains

[Ryan Sleevi]

Right, I'm aware you, as an individual CA, may not, but the BRs
1) Don't place any requirements beyond documenting and having a procedure
for those flagged High Risk. The procedures may simply be "We require a
phone call and a pinky promise to be good"
2) Don't place any requirements on the criteria for a request being flagged
as High Risk, other than all EV certs are automatically high risk.

Thus while you won't issue for microsoft.example.com or
googleserver.example.com (and, to be fair, TrendMicro certainly will issue
certs for those names, since it seems you will sell *.example.com), another
CA may, and without violating any requirements. This is true whether the CA
is issuing for DV or EV.

I'm not trying to be stubborn here, but again, it is worth reiterating that
nothing in the BRs or EVGs requires that a CA treat a request for
facebook1.com any different than facebook2.com, or fbcdn.com any different
than fcbdn.com, beyond the ambiguous and underspecified "addition
verification activity", and if and only if the CA deems it high risk (which
they may not). They do not prohibit a CA from issuing these certs, so I see
no reason why .onion should be any different, especially since certificates
are not an anti-phishing tool.

My goal in arguing for these certs is I believe they are a great tool to
increase online privacy and security, and, from a validation and
verification space, are not weaker than the existing DV and EV practices.
Indeed, in very real ways, this proposal is actually stronger than some of
the verification practices CAs currently use (e.g. it requires a
cryptographic key binding the name, rather than the insecure and
unauthenticated reliance on DNS)

I am concerned that the questions on criteria from my previous mail were
somewhat ignored. I definitely think that if there are opportunities to
improve this ballot, we should take them. However, your previous comment
regarding "randomness" doesn't really establish actionable, auditable,
objective criteria, and proposes to require more than the BRs require or
CAs practice. I'm not sure how we can reasonably satisfy your concerns
because of this, nor whether the absence of a solution for a problem the
BRs don't address means you will vote to leave .onion unvalidated and
unregulated, and, as a consequence, untrusted by some UAs (notably, Chrome).
On Feb 12, 2015 10:23 PM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:

>  *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 <
> 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 and facebookcorewww1.com from
> purchasing certificates, EV or DV, provided they demonstrate control over
> that namespace. Why would or should .onion be any different?
>
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20150212/0cecb770/attachment.html