[cabfpub] Revised document for Ballot 89 - Adopt Requirements for the Processing of EV SSL Certificates v.2

Ryan Sleevi sleevi at google.com
Mon Oct 15 20:59:29 UTC 2012


On Mon, Oct 15, 2012 at 1:09 PM, Hill, Brad <bhill at paypal-inc.com> wrote:

>  And we should move this to a public participation list like those hosted
> by Mozilla.****
>
> ** **
>
> Again, this is an issue of broader ecosystem security that directly
> impacts implementation, operational and trust decisions in the user
> community, and as such is out of scope for the CABF.  In fact for the
> issues being discussed there is no impact or involvement of CAs at all.
>

I'm not sure I'd fully agree with this statement. The biggest concern here
expressed in Rick's comments seems to be related to how information is
presented. If a certificate (DV, OV, or EV) makes signed assertions beyond
the nature of the public key, then that is currently presented in a
particular UI. A number of Rick's criticisms have focused on areas of
potential confusion, where presenting information obtained via DNSSEC as
authentic/validated (such as subject name or X.509v3 attributes) would be,
at best, misleading, and at worst, undermine the security or
trustworthiness of CA certificates.

To the extent that there are quantifiably different security guarantees
afforded by DANE than with PKIX certificates, this seems a reasonable forum
to discuss possible presentation/user-interface issues that CAs feel are
important - much like the Forum reached some degree of consensus on the
branding of EV vs DV/OV. While browsers will naturally implement the UIs
that they feel best meet the needs of their users, it seems important to
solicit feedback from stakeholders - both in DANE and from the CA/B Forum
membership - on particular concerns or issues for their respective
organizations and industries.

While I don't disagree that there are still conversations to be had in the
wider community, I do disagree with the characterization that such
communications may not also happen in the Forum, which is presently the
best method of communicating between root program operators (browsers) and
certificate authorities.


> ****
>
> ** **
>
> As such, this fairly reeks of anti-trust issues, looking pretty much
> exactly like an oligopolistic group of insiders trying to use their
> collective influence to limit or lock out a competitive alternative.****
>
> ** **
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Monday, October 15, 2012 10:50 AM
>
> *To:* Rick Andrews
> *Cc:* Hill, Brad; public at cabforum.org
> *Subject:* Re: [cabfpub] Revised document for Ballot 89 - Adopt
> Requirements for the Processing of EV SSL Certificates v.2****
>
>  ** **
>
> Hi Rick,****
>
> ** **
>
> Thanks for taking the time to engage on this side-discussion. I have
> further comments inline, but if you wish, we can separate this out into a
> different thread independent from the proposed ballot discussion, since
> we're going further away from the original proposal :)****
>
> On Sat, Oct 13, 2012 at 4:23 PM, Rick Andrews <Rick_Andrews at symantec.com>
> wrote:****
>
> Comments inline.****
>
>
> > -----Original Message-----
> > From: Ryan Sleevi [mailto:sleevi at google.com]****
>
> > Sent: Friday, October 12, 2012 5:50 PM
> > To: Rick Andrews****
>
> > Cc: Hill, Brad; public at cabforum.org
> > Subject: Re: [cabfpub] Revised document for Ballot 89 - Adopt
> > Requirements for the Processing of EV SSL Certificates v.2
> >****
>
> > On Fri, Oct 12, 2012 at 5:32 PM, Rick Andrews
> > <Rick_Andrews at symantec.com> wrote:
> > > Brad,
> > >
> > >
> > >
> > > I would say a DV cert is superior to DANE w/o PKIX because:
> > >
> > > -          The DV cert will conform to Baseline Requirements (minimum
> > key
> > > size, strong signing and hashing algorithm, acceptable validity
> > period,
> > > proper extensions)
> >
> > Under DANE Certificate Usage Type 3, the purpose is to effectively
> > deliver a public key. No other asserted information is particularly
> > relevant to the connection - it's simply the provisioning of the
> > peer's public key via out of bands means. This is further reflected in
> > the IETF, where proposed extensions to TLS specifically recognize the
> > need to avoid certificates.
> >
> > So the use of a certificate is more akin to a "key delivery mechanism"
> > than it is about delivering signed assertions. Issues such as validity
> > period or extensions are irrelevant - they are handled at the DNSSEC
> > layer.****
>
> I would say the validity period is relevant. Why do the EV Guidelines
> restrict EV certs to 2 years max, and the BRs restrict OV and DV to 4 years
> max? It seems to me that since DANE doesn't restrict how long a key is
> used, and doesn't even let you determine the age of the key, that's a
> security hole waiting to be exploited.****
>
> ** **
>
> Because DANE is simply a binding of name to public key, and it is
> delivered through the same mechanisms used to resolve names.****
>
> ** **
>
> The public PKI is a binding of name to public key **and some validated
> attributes**, and is delivered through a mechanism that is **independent*
> *of the method used to resolve names.****
>
> ** **
>
> The whole value premise of EV is that the extended attributes have been
> vetted more rigorously than DV or OV. So in a world where effective
> revocation checking is not yet viable - and we have to acknowledge that as
> long as a vast majority of legacy and present-day clients do not support
> revocation hard fail - the once a certificate is issued, it may be
> considered to be unrevocable for a non-trivial set (majority?) of internet
> users. Expiration serves as a natural revocation, and serves to ensure that
> the asserted validated attributes are in fact re-validated as authentic on
> a periodic basis.****
>
> ** **
>
> For example, if a DV cert was issued with a 10 year validity, but the
> registrant had only registered it for five years, what does that mean for
> the new owner of that domain? It would mean (some unknown set) of
> certificates exist, floating around the Internet, that could be used to
> impersonate their services.****
>
> ** **
>
> With DANE, these concerns aren't appropriate, since no validated
> attributes exist (other than the public key), and the authorization to use
> the domain is self-evident by the DNSSEC chain of trust.****
>
>  ****
>
>
> > > -          The DV cert would be very likely to have undergone
> > automated
> > > checks for weak keys, weak exponents, not on Debian weak key list,
> > not on
> > > internal phish lists, etc.)
> >
> > "Very likely", considering that the Baseline Requirements put this as
> > a SHALL (eg: MUST). However, because the Baseline Requirements do not
> > currently specify any minimal assurance level, from the perspective of
> > a relying party (and a browser), there is no minimum level of
> > confidence that can be assessed to a CA cert here.
> >
> > For example, I believe the discussions regarding Unicode "confusibles"
> > highlights that even under the BR or EV certification regimes, there
> > is still ample opportunity for abuse.****
>
> But with DANE w/o PKIX, it's almost certain that no checking was performed
> for weak keys. The person who generated the key probably won't, and the DNS
> operator probably won't either, because they're not required to. I can tell
> you that Symantec, for all its brands, checks for Debian weak keys and
> thousands of domains on our internal phish lists. I would guess that most
> major CAs also do that.****
>
>  ** **
>
> Strictly speaking, cases of server misconfiguration, which I would include
> weak keys among, do not give me the greatest trouble when I go to sleep at
> night. It's troubling in that it happens and that, in many cases, it's
> perhaps terribly easy, but those are typically smaller sites that are not
> familiar with best practices. There's nothing to prevent site operators
> from storing their SSL private key in a publicly available file path
> either, and I'm not sure there are defenses against it in either system.**
> **
>
> ** **
>
> Checks for things such as weak keys are to help manage expectations that
> when a CA issues/certifies a certificate as "This is trustworthy for X, to
> the best of my knowledge and ability". If there are things are obviously
> problematic, then I agree, the CA issuance is the best, and likely only,
> time that these issues can be signaled to the site operator. But I don't
> know if it's the most important or valuable proposition of the PKIX system.
> ****
>
> ** **
>
> What does give me trouble at night is the risks presented to sites that do
> everything right, but which cannot control external variables like how
> trust is ultimately determined, which is why I'm so supportive of work like
> CAA, Certificate Transparency, and Public Key Pinning, and which DANE seems
> to offer an interesting (although incomplete) combination of.****
>
>  ****
>
>
> > > -          The DV cert would contain AIA and/or CDP extensions, so if
> > the CA
> > > detects that the site is fraudulent, it can revoke the cert.
> >
> > And how is this different from the registrar revoking the DNS
> > registration (eg: due to a WIPO UDRP typosquatting claim)?
> >
> > The DNSSEC approach has the potential at a greater turn-around (due to
> > being constrained by the validity of the DNS response), rather than
> > the 3-10 day publication period for CRLs and OCSP information.****
>
> I'm not very familiar with WIPO UDRP, but if that only covers
> typosquatting claims, then it doesn't cover taking down the site if it's
> being used for fraud.****
>
>
> > >
> > >
> > > I feel strongly that a site (either real or fake) with a self-signed
> > > certificate with a 30-year validity, containing a 1024-bit Debian
> > weak key,
> > > no basicConstraints or CA=true should not be given the same "trusted
> > cert"
> > > status indicators as a DV cert.
> >
> > The 30 year validity is inconsequential - it is the DNSSEC's cache
> > time that provides the time validity information. Neither does the
> > basicConstraints extension have any effect, since again, the
> > certificate is simply a "public key delivery method" (Type 3 is very
> > constrained to the *end-entity* certificate)
> >
> > The only issue with this specific example is with regards to a
> > 1024-bit Debian weak key, but this, along with other such "security
> > failures", are checks that are being jointly implemented by both CAs
> > (at time of issuance) and Browsers (at time of verification), as a
> > form of defense in depth. So even under a DNSSEC/DANE regime, there is
> > still defense against this class of errors.****
>
> I know of no browser that's building in Debian weak key checks. That's
> best done at the CA, because then we can tell the customer about it. What
> will a browser do? Tell the user to tell the web site operator that their
> key is weak?
>
> Another point I'd like to make is that if you move away from the CA model
> (even with a DV cert) to a DNSSEC-based DANE w/o PKI, you're shifting your
> trust to the operators of the various DNS zones and domains (for DNSSEC
> PKI) and to millions of individual domain owners (for generating and
> maintaining their keys). None of those entities are subject to audit like
> the CAs are, and it's reasonable to assume that there are no standards and
> hence we'll have good ones and bad ones. That makes the end user less safe,
> in my opinion. Imagine Diginotar in the DNSSEC business...****
>
>  ** **
>
> Here again, DANE is slightly different. In the Diginotar case, the
> compromise of Diginotar allowed misissuance for any domain in the world -
> including google.com - even though as a CA, they were primarily focused
> on local issuance in the Netherlands. This is the same risk that exists for
> the compromise of any CAs that are publicly trusted - one compromise
> affects all sites on the Internet. This is why we (along with others) are
> such big fans of Certificate Transparency, as a means to mitigate some of
> these risks through greater visibility.****
>
> ** **
>
> Compare this to DANE, which has a different set of security/threat
> guarantees.****
>
> - If I compromise a single sites' DNSSEC key, I can only compromise at
> that hierarchy and below (eg: google.com). This is (generally) no
> different than if I can compromise their SSL key or DNS administration (to
> induce issuance of new keys)****
>
> - If I compromise a domain registrar, then I can compromise any unlocked
> domains managed by that registrar  This is no different than the security
> premise of DNS today.****
>
> - If I can compromise a domain registry (eg: a gTLD), than I can
> compromise all sites beneath that hierarchy (eg: all of .com). However,
> this is still strictly less than all sites on the internet, and is
> functionally no different than a name-constrained CA certificate.****
>
> - If I compromise the root, then I can compromise all sites on the
> Internet.****
>
> ** **
>
> The premise of DANE, particularly with Type 3, is that it effectively acts
> as name-constrained CA certs, which have been previously discussed, and
> with only a single authority at each level. The effective security of
> google.com, in a DANE world, is the effective security of (Google's
> KSK/ZSK for google.com, Verisign's KSK/ZSK for .com, ICANN's ZSK/DSK for
> root).****
>
> ** **
>
> The premise goes that if a site operator (eg: Google) is not happy with
> the key management policies of a TLD/gTLD, they can simply use and register
> a name under another TLD/gTLD where they are comfortable. The security
> decision rests in the hands of the site operators, whereas today, site
> operators are at the mercy of the browsers/root store operators to require
> best security practices by the CAs who are being admitted into their
> programs - and without a participatory venue such as the Forum to express
> these concerns in.****
>
> ** **
>
> Even under DANE, as Chris Palmer mentioned, there is still value in
> Certificate Transparency, as it serves as a defense against registrar
> misissuance or coercion, whether illegitimate (hack/compromise) or
> legitimate (legal mandate).****
>
> ** **
>
> However, the risks to end-users */seem/* to be measurably less, in that
> site operators now have full say in choosing a registrar that meets their
> security guarantees. Compare this to today's model, where site operators
> have limited say in what CAs could be induced to misissue on their behalf.
> Public Key Pinning and CAA go a good deal to addressing some of these
> concerns, but hopefully these differences are now clearer.****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121015/db6ae139/attachment-0004.html>


More information about the Public mailing list