Fwd: Re: [cabfman] Improving the security of EV Certificates

[Rob Stradling]

FYI...

-------- Original Message --------
Subject: Re: [cabfman] Improving the security of EV Certificates
Date: Mon, 4 Nov 2013 15:57:02 -0800
From: Rick Andrews <Rick_A...@symantec.com>
To: manag...@cabforum.org <manag...@cabforum.org>

Symantec's position on Certificate Transparency:

On September 24, 2013, Ben Laurie solicited comments on Google's plan
for Certificate Transparency (CT), specifically to require the use of CT
for all EV certs issued after a certain date. Symantec is in favor of
making the web more secure, and in particular, helping to prevent
certificate mis-issuance. In our view, there are many ways to do this,
and CT should be evaluated along with other proposals and compared to
them. We first present feedback on CT itself, then feedback on the plan
to require CT for EV.

Certificate Transparency

After some cases of CA flaws were publicized in 2011, several proposals
were made to enhance the current browser-CA-based trust model, since the
incidents showed that a poorly managed CA could mis-issue a trusted
certificate. Well before those events, both CAs and browsers
collaborated on a set of Baseline Requirements that went into effect on
July 1, 2012. In addition, both CAs and browsers have taken additional
steps by themselves to help customers and users be more secure. It is
noteworthy that since these steps have been taken, the empirical
security of the CA/Browser ecosystem has demonstrably increased.

This trust model that has been built into browsers is a very complex
system, yet in our opinion, CT proposes to address mis-issuance by
building another complex system that will no doubt have its own share of
complexities and challenges. We can't be sure that the combined system
(browser-CA-based trust model plus CT) will necessarily be better or
more secure, especially since CT cannot prevent mis-issuance, but can
only help in detecting of mis-issuance. And mis-issuance can't be
detected until the log servers have incorporated the certificate (within
the Maximum Merge Delay) and monitors have queried all log servers. A
denial of service attack against a log server could extend the time
during which a mis-issued certificate could be used. We favor solutions
that are preventative in nature.

We note that the CT spec offers options for delivery of CT proofs, also
known as SCTs. The first option would require a CA to obtain multiple
SCTs and insert them into the certificate before signing it. Other
options would not impact the certificate issuance process but would
allow the CA or the customer to obtain SCTs after cert issuance. We
expect strong pressure to support the first option, because it has the
great advantage of working with existing web servers with no
configuration change. The other options require code and/or
configuration changes in web servers that would greatly slow the rollout
of this technology.

Our main concern with the first option is that it requires the CA to
make extensive changes to its issuance process that create an external
dependency outside of the trust provider's control. That process is most
critical for a CA, since it is how the CA confers legitimacy onto
trusted web sites and achieves its business objectives. We believe that
it would be analogous to asking Google to get approval responses from
external entities before it could publish an advertisement or publish
web search results. There is no doubt enhanced risk in making such
external calls. If responses are not received from the minimum number of
log servers, the CA would not be able to issue the certificate. (We note
that CAs already consult external services like Dun & Bradstreet and
whois in their authentication processes, but those services have proven
to be extremely reliable, and even if they weren't, they are not
essential to the process - there are workarounds.)

The CA could mitigate the risk of relying on external services by
running its own log servers. Google has generously offered source code
for this purpose. Each CA would have to choose between running one or
more log servers themselves or relying on log servers run by others. The
former involves considerable cost, the latter involves considerable
risk. The expense of building and maintaining such log servers will be
outside the reach of many small CAs, since the log servers would have to
have an extremely low failure rate and would have to respond with very
little latency even under very high load. As a high performance and
highly-scaled player, one could argue that Symantec stands to benefit
from this regulatory requirement. However, we believe investment choices
must be paired with an analysis of the benefits created and new costs
incurred from a potential solution. In this case we do not see how CT
raises the bar enough to justify added risk, costs and complexity.

Symantec is reluctant to invest large sums in unproven technology that
introduces substantial ecosystem rigidity and potential for points of
failure. Note that even if external logs work perfectly with 100%
uptime, other factors (ISP failure, DOS attacks, etc.) could prevent the
CA from obtaining enough SCTs to issue the certificate. The CA could run
some internal log servers and rely on some external log servers, but
Symantec believes that combines the worst features of both options. We
admire Google solutions that combine simplicity, speed and user-centric
design. Our fear is that CT will sour SSL customers on the trust
ecosystem, while not delivering on what we believe should be the number
one goal: preventing mis-issuance at the source.

If a CA deploys their own log server, that server needs to handle not
just the load from the CA but from all the monitors that will frequently
hit it. CT imposes no restrictions on log monitors, so the log server
operator has to plan for very high load.

Another concern with the first option is the extent to which CT will
increase certificate size. Adding the recommended three SCTs to a
certificate will increase the size approximately 300 bytes. This comes
at a time when several high profile customers and Mozilla have asked us
to reduce the size of our certificates. Option 1 also increases the
burden on CAs by requiring each certificate to be signed twice. Signing
infrastructure is one of the largest investments that a CA makes, since
keys are generally kept in expensive Hardware Security Modules. Option 1
would require CAs to double that investment.

But the CA can choose a second option for SCT delivery, in which SCTs
are not obtained at certificate issuance time. The web site owner, or
the CA on behalf of the web site owner, could obtain SCTs sometime after
the certificate is issued. But unless the customer uses a web server
that supports delivery of SCTs via a custom TLS extension (meaning that
they would have to upgrade or at least reconfigure their web server to
support CT), they would not be able to serve SCTs to clients.

A third option would allow SCTs to be carried inside of an OCSP response
message. While that option has the appeal of leaving the certificate
issuance process untouched, CAs would need to make extensive revisions
to their OCSP response architectures to obtain the necessary SCTs and
embed them in the OCSP response. The level of effort would be roughly
equivalent to the effort required to support the first option,
incorporating SCTs in the certificate. Some CAs use third party software
to create and publish OCSP responses, and wouldn't have the ability to
affect the changes needed to support this option. It seems that
CT-compliant browsers would need to support all three options for SCT
delivery, in order for each CA to adopt the option that best suits it.

The specification is unclear on who would audit the log servers,
verifying that the log server's log included a certificate for which it
issued an SCT, and that it was done within the MMD time. Perhaps that
will be done by the browser, asynchronously. But this function is
crucial - without it, users are simply trusting log servers instead of
CAs. Symantec is unwilling to invest large sums in a technology for
which it's still unclear how crucial tasks will be performed.

Also missing from the specification is a mechanism that can be used by a
monitor to determine the location of all log servers. If a monitor
misses any log servers, it may miss one or more mis-issued certificates.
New log servers may appear from time to time, while existing log servers
may become untrusted if auditors detect any improper function. It's
essential that monitors have a way to always know the full set of
trusted log servers, but no mechanism is detailed in the CT specification.

Symantec is also concerned about privacy. It's true that most TLS
certificates are public information, but CT logs collect all TLS certs
in a convenient, easily accessible database. We are concerned about the
possibility of the misuse of this information, for example, creating an
easy way to target certificate owners with unwanted solicitation.
Requiring CT for EV certificates

In regards to requiring CT for EV, we note that there has been active
discussion recently in the CAB Forum on adding run-time checks before
displaying the EV treatment. It appears that this would be one such
run-time check. There has been and continues to be strong opinion (maybe
even consensus) in the CAB Forum that EV is about validation only, not
enhanced run-time checks. Symantec believes that adding run-time checks
will enhance security, but we would prefer to begin with checks for
which there is probably broad consensus (key size, validity period,
wildcard, etc.) rather than beginning with a heavyweight CT requirement.

As mentioned above, CAs are free to choose the option of delivering SCTs
outside of the certificate issuance process, but customers may then be
forced to upgrade or at least reconfigure their web server just to
preserve EV treatment. Since few customers will be happy about that,
Symantec believes that CAs will have no choice but to forgo this option
and obtain SCTs at certificate issuance time. That will force CAs to
choose between considerable expense and unacceptable risk, as described
above.

Given all the concerns described here, Symantec strongly believes it is
unadvisable to mandate the use of CT. At the very least, we believe
additional study is required on how to overcome the challenges of CT.

More technical details need to be worked out. For example, the
specification says "this document does not describe how clients obtain
the logs' public keys"; it's also not clear who would serve as auditors,
and unless the logs are constantly audited, the integrity of the system
is degraded or lost. We note that all CAs are required to be audited,
and it would be equally important to insure that all log servers are
audited.

We hope that Google will continue to discuss this within the CAB Forum
and try to work towards consensus among other browser vendors and CAs.
The EV Guidelines were crafted by that Forum, and we believe that any
change to the EV guidelines or to the requirements for display of the EV
treatment should be debated and agreed to by the Forum, not unilaterally
by Google.

Symantec's proposals

Symantec believes that log servers do provide some benefits for domain
owners who want to monitor the issuance of certificates for their
domain. But the proposed method of populating log servers is, in our
opinion, complex and expensive. We suggest a compromise in which the
owner of a log server populates that server with certificate information
found via a web crawl. In fact, Google has been populating a log server
this way for the last few months, and it has already discovered a
suspicious certificate chain. Symantec is considering the possibility of
performing a periodic web crawl and populating its own log server with
all certificates found. This approach requires a much smaller initial
investment and results in a much simpler system. A monitor would have to
monitor a single log server, and it need only be monitored by the log
owner, not the public at large.

Symantec also would prefer to invest in technology that has the aim of
adding even more mechanisms to prevent mis-issuance before it happens.
To that end, we are building support for Certificate Authorization
Authentication (CAA), a relatively simple idea that has the potential to
prevent mis-issuance. We will urge other CAs to seriously consider
adopting CAA as well, and we suggest that the CAB Forum make use of CAA
a Baseline Requirement. Absent that, if the browsers shared the goal of
preventing mis-issuance at the source they could require use of CAA for
inclusion in root programs. Alternatively, CAs that utilize CAA could be
differentiated by browsers through simple user-centric markings in the
browser and/or user choice on what roots to trust while browsing. CAA is
not a panacea but does create a straightforward method for concerned
domain owners to limit the potential for mis-issuance. At Symantec we
are always continuing to investigate other technologies.

We note that public key pinning and HSTS have been very effective in
detecting mis-issuance for some web properties, especially Google. The
main shortcoming of pinning appears to be scalability, but Symantec
suggests that a modest investment in addressing the scalability problem
would pay huge dividends. We support the continued adoption of key
pinning and HSTS, and we continue to investigate other solutions for
improving the browser-CA trust model.

We close by offering that these comments are in the spirit of a robust
public discussion on the future of web security and have no doubt that
all parties including Google desire a safer Internet. We hope to
continue an active dialogue that looks for ways to reduce risk while
continuing to enable the web security ecosystem to flourish and scale to
provide even more benefit for the Internet. We invite feedback and
comment on our statements and look forward to continuing the discussion.

-Rick

> -----Original Message-----
> From: managemen...@cabforum.org [mailto:management-
> bou...@cabforum.org] On Behalf Of Ben Laurie
> Sent: Tuesday, September 24, 2013 2:46 AM
> To: manag...@cabforum.org
> Subject: [cabfman] Improving the security of EV Certificates
>
> We invite your comments on this document.
_______________________________________________
Management mailing list
Manag...@cabforum.org
https://cabforum.org/mailman/listinfo/management

[Brad Hill]

Regarding Symantec’s suggestion of a crawl of publicly exposed certificates: this has been done, of course, a number of times already.  It has exposed incompetence and technical malfeasance by CAs on a large scale yet it has not prevented subsequent breaches of trust.

 

In the wake of the Snowden revelations, we are in the very midst of the largest and most public set of information security and trust policy discussions in history.  As pervasive surveillance and active attacks have been revealed to be perpetrated by multiple state-level actors with incredibly sophisticated capabilities, acting both at the backbone and internally on many networks, and with leaked top-secret documents on SSL attacks containing arrows labeled "CA service requests", is is both absurd and embarrassing for Symantec to suggest that a survey conducted over the public network would be in any manner adequate to re-establish and maintain trust in the system.

Brad Hill

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.