[cabfpub] Ballot .onion ballot

[Ryan Sleevi]

On Thu, Feb 5, 2015 at 9:44 AM, Eddy Nigg <eddy_nigg at startcom.org> wrote:

>
> On 02/05/2015 04:26 PM, Gervase Markham wrote:
>
> I'm not the person who argued for a restriction on *.facebook.com EV
>
>
> I too might be wrong on this, but according to my memory I recall that you
> were the person arguing against it when we discussed it last time when we
> created the BR. :-)
>
> IIRC Wayne from Godaddy argued (correctly) that if wild cards should be
> restricted it would make most sense to have it supported by EV since it's
> the strongest verification standard currently. EV allows to include domain
> names of third parties (in my opinion incorrectly), so adding wild cards
> doesn't change that in any way really.
>
> We would be in favor for such a move and believe that wild cards have
> nothing lost in the non-verified (e.g. DV) settings due to their potential
> abuse. If at all, wild cards should be permitted with EV and prohibited for
> DV (if you want anything else than EV).
>

At the risk of derailing the conversation, we'd be opposed to such a
proposal (and have said so in the past)

To the topic at hand - as it relates specifically to .onion names:

The case for wildcards:
- The use of origins (RFC 6454 for those unfamiliar with the core concept
of web security) provides an effective means to separate privileges and
reduce the risks of compromise (in the web sense; this means issues such as
XSS) and the privileges granted
- The use of separable origins can be beneficial-to-critical to high
performance web pages (... unless/until the site is using HTTP/2), due to
items such as connection pooling, request prioritization, etc

The case against wildcards:
- The primary argument against wildcards (for EV) is derived from Section
11.12.1 of EVG 1.5.2. EVG 1.5.2 requires all names be treated as High Risk
(as defined in the BRs 1.2.3), which requires that the CA perform some
degree of secondary checks (such as names listed on Miller Smiles or Safe
Browsing). A wildcard cert allows an entity to request a potentially
confusing name (bankofamericacom.facebook.com) that may phish the user.
- The secondary argument against wildcards is derived from Section 11.7.1
p2 of EVG 1.5.2, the prohibition against mixed script. A wildcard allows a
certificate holder to find any valid construction of IDNA/script at that
subordinate domain that may exploit some confusible.

Now, I don't feel that the case against is at all strong or relevant. It's
long been public record that we don't view certificates as an effective
means against phishing, for a wide variety of reasons, and so
phishing-level arguments are, to us, particularly specious. The argument
against mixed script is also questionable, in as much as it's possible with
DV, and it's an issue that browsers (and their rules regarding presentation
of punycode vs native scripts) are already handling. For !browser clients,
it might be relevant, but I would argue that the EVGs are not exactly
relevant to the !browser case.


To the broader question about whether wildcards should be prevented or
allowed in the EVGs, I suspect this will be the same tension and misaligned
interests as the insurance discussion. CAs may perceive one set of value
propositions, browsers another. The lack of wildcard support allows for
greater price controls, which on a purely business level is a boon, but on
a practical security level, would be unfortunate if CAs place profit over
security.

However, if this does represent some set of concern for CAs (although I
would argue unwarranted, for the reasons explained above), then I suspect
it can be removed. It just means anyone wanting to use hidden services for
accessibility (e.g. as Facebook is doing) will need to invest sizably more,
or work out an appropriate cost structure with the CA that allows for bulk
purchase, neither of which do much to change the security landscape any.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150205/fcc0f41f/attachment-0003.html>