[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 10:49:37 MST 2012


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://cabforum.org/pipermail/public/attachments/20121015/14d3d57f/attachment-0001.html 


More information about the Public mailing list