Re: Certificate Authority Weaknesses [was Re: Issues of concern to the TAG]

To further this point:  Google security researchers have indicated that the
CA situation is so dire that future versions of Chrome may not even bother
with real-time CA checking anymore.
http://www.imperialviolet.org/2012/02/05/crlsets.html

Points of note:

   - For years, browsers have ignored failed certificate validations when
   the CA is unreachable.  Why?  Because you don't want half the internet to
   go down just because Verisign (or any popular CA) has a 30 minute outage.

   - When CAs are hacked, the OCSP caching of certificates for 7 days is so
   long, that all major browsers (IE, Firefox, Chrome) will just send updates
   rather than wait for the cached OCSP responses to expire.  We've built a
   system where it is more effective to patch 1B users than it is to rely on
   the default security mechanics.

   - We really have no idea who the browsers trust anymore - nobody knows
   the exhaustive list of who has been delegated trusted signature authority
   at this point.

This is a really big problem.  I don't have a good answer.

Mike





On Wed, Feb 15, 2012 at 8:13 AM, Noah Mendelsohn <nrm@arcanedomain.com>wrote:

>  At the TAG's F2F meeting in June of 2011, Jeff Jaffe asked us to
> periodically provide him with reports on technical and architectural issues
> that the TAG believes should be of concern to the W3C. We provided our
> first such report to Jeff last week, and with his permission, I am
> forwarding this copy to www-tag@w3.org.
>
> Discussion is encouraged, but since multiple topics are covered, it may be
> helpful if you change the subject line of any responses so that we can keep
> separate threads for the various issues. Thank you.
>
> Noah
>
> -------- Original Message --------  Subject: Issues of concern to the TAG  Date:
> Sun, 12 Feb 2012 09:23:45 -0500  From: Noah Mendelsohn
> <nrm@arcanedomain.com> <nrm@arcanedomain.com>  To: Jeff Jaffe
> <jeff@w3.org> <jeff@w3.org>  CC: TAG Member List <tag@w3.org> <tag@w3.org>
> Jeff:
>
> At our June, 2011 F2F meeting of the TAG, you requested [1] that we
> periodically alert you to developments that we perceive as threatening the
> technical integrity or success of the Web. This is the first such report.
>
>    - Weaknesses in the Certificate Authority System
>
>    HTTPS, the secure protocol used for access to resources identified
>    with https-scheme identifiers, depends on the the worldwide hierarchical
>    system of Certificate Authorities to validate that users are connecting to
>    the the correct sites. In 2011, various attacks on CA systems led to the
>    creation fraudulent certificate for known sites, allowing man-in-the-middle
>    attacks for SSL protected sites (including social network sites, banks,
>    etc...).
>
>    We highlight this issue for several reasons:
>       1. HTTPS is the foundational protocol for secure and private use of
>       the Web. When HTTPS is compromised, the Web becomes unsafe for secure or
>       private communication.
>       2. In some parts of the world, fraudulent certificates used in
>       conjunction with DNS hooks or other man-in-the-middle techniques threaten
>       the interception of politically sensitive communications. Lives may be at
>       risk as a result.
>       3. At the present time, there is no obvious solution that seems
>       likely to reduce the risk of fraudulent certificate creation to an
>       acceptable level.
>
>    The TAG has become aware of this issue through various news reports,
>    and also through a request from Harry Halpin that the TAG investigate [2].
>    A discussion with Harry and Thomas Roessler is on the agenda for the TAG
>    teleconference of 19 January 2012. Among many other important concerns, the
>    impact on the W3C specifications level needs to be assessed.
>
>    At it's F2F in January 2012, the TAG requested that we highlight this
>    to you as an issue of greatest importance.
>    - SPDY and HTTP
>
>    Recent developments suggest that competitors are emerging to HTTP 1.1,
>    which is the core protocol of the World Wide Web. These developments are
>    motivated by the observation that HTTP is inefficient in the many cases
>    where a single Web page is assembled from many separate concurrently
>    retrieved HTTP resources, and also that current implementations of HTTP put
>    a strain on the lower layers of the TCP stack (partly due to lack of or
>    broken implementation of some performance-related optional features of
>    HTTP/1.1 as well as some issues in TCP implementations, see Jim Gettys' and
>    Kathleen Nichols' ACM Queue article on Buffer Bloat [3]). Google's SPDY
>    protocol was created to address these performance issues; several other
>    proposals like HTTP over SCTP, or Waka are also being investigated and are
>    at differing maturity levels.
>
>    SPDY, which has benefited from the most implementation experience and
>    deployment, retains HTTP's application model including headers, status
>    codes, entity bodies etc., but multiplexes multiple HTTP interactions in a
>    flexible manner over a single SSL connection. SPDY is already used by
>    default for connections from Chrome to many Google properties, and Firefox
>    support for SPDY was recently deployed in experiemental form, SPDY is on
>    the roadmap of widely used HTTP servers and open source libraries are
>    starting.
>
>    We highlight this issue because HTTP is the core protocol of the Web
>    stack, and so any change, improvement or new version might have huge impact
>    on the whole Open Web platform. Existing deployments of SPDY use SSL for
>    tunneling through existing proxies, which raises architectural questions
>    relating to caching, certificate management, etc. The TAG met during TPAC
>    with Mike Belshe, one of the co-authors of SPDY. At our recent F2F [4] we
>    also met with Mark Nottingham (IETF liaison with W3C), and discussed with
>    him IETF plans in this area. The TAG will continue to track developments
>    relating to new versions of or replacements for HTTP, but we are satisfied
>    that at least for the moment, the IETF is taking the appropriate steps in
>    this space.
>    - Specifications with the same scope
>
>    Since the creation of W3C, specifications with what seemed to be the
>    same scope were developed. CSS and DSSSL in 1995 was an early example.
>    Issues start to arise when similar specifications are used outside of their
>    main context and clashes can occur:
>       - Canvas/SVG (although there are specific use cases for both)
>       - Microdata/RDFa (See below)
>       - XSL/CSS
>
>    Even more recently, XPath and CSS Selectors were subject of
>    discussions [5] that led to the understanding that it was not a substantive
>    issue. This happens when one set of technology reengineers or adapts
>    solutions done by another set of technologies.
>
>    The Microdata/RDFa conflict was raised during the TAG's review of
>    HTML5. It led to the creation of a Task Force[6], and the publication of
>    two documents (See [7][8]) to address some real identified issues.
>
>    As technology stacks evolve and cover new grounds, other collisions
>    can and will occur. The TAG, as part of its review activity will continue
>    to monitor such issues, and alert you when major issues are detected.
>    - Native mobile & tablet applications vs. Web applications
>
>    Native application environments are currently the platforms of choice
>    of development of most applications for mobile devices. This is due to a
>    combination of factors:
>       - We lack a shared understanding of the security model for
>       privileged application as well as for application lifecycle beyond the
>       simplest cases.
>       - There is a functionality gap between the capabilities of native
>       platforms and the Web platform. This is primarily due to the fact that, it
>       is faster to ship a proprietary feature than the same one through a
>       specification with multiple interoperable implementations.
>       - The "monetisation" ecosystem for Web applications is not as well
>       developed as for native applications that benefit from app stores.
>       - Projects that take a stab at creating mobile platforms based on
>       Web technology (e.g. WAC, Tizen) suffer from a lack of documentation of the
>       design preferences and best practices in Web API design.
>
>    Because of this, there is a risk that barring a coherent push to
>    improve the core Web platform for mobile devices native applications will
>    remain dominant over the next ten years. This risk is however mitigated by
>    several factors:
>       - The W3C has a strong investment in improving the Web application
>       platform, notably in the mobile area.
>       - Many developers who ship their applications as native in fact use
>       so-called "hybrid" systems in which they create Web applications that are
>       wrapped in native containers. This enables them to transition to Web
>       applications with minimal effort.
>       - Major efforts are made in the industry to strengthen the Web as
>       an application platform, notably for mobile devices. These include
>       Mozilla's Boot To Gecko, Microsoft's Windows 8, and Samsung + Intel's
>       Tizen. Their experience is feeding into the production of open standards.
>
>    As a result, there is a window of opportunity for the Web platform to
>    disrupt mobile application development faster than it did on the desktop.
>    - Distributed extensibility and CSS vendor prefixes
>
>    We're still trying to manage distributed extensibility, but the
>    mechanism the CSS WG was using is now under threat. Mozilla and Opera are
>    currently making plans to implement support for -webkit- prefixed CSS
>    properties in their respective browsers. They feel they are being driven to
>    this due to the large amount of mobile web content that only provides
>    -webkit- prefixed properties despite the availability of equivalent
>    prefixed properties on Gecko and Presto.
>
>    If browser vendors begin implementing other browser's proprietary
>    properties, the entire standards process is in danger of getting usurped.
>    This also puts the plan to apply vendor prefixes in another areas (such as
>    JavaScript) at risk as the primary purpose for having vendor specific
>    prefixes is being bypassed.
>
>    The CSS working group may make progress in limiting long-term
>    deployment of proprietary extensions that would be better standardized, but
>    prospects for success aren't entriely clear.
>
>  We hope you find this to be useful. Unless you suggest to the contrary,
> we will continue to prepare reports like this for you approximately twice
> each year, as you requested in June.
>
> Also: in keeping with our mandate to work "in public" whenever practical,
> the TAG is inclined to send copies of this and future reports to our public
> mailing list. Since this work was done in response to your personal request
> for TAG input, we wanted to first check whether you agree that doing so is
> appropriate. Obviously, we will make exceptions if any future report
> contains unusually sensitive or member-confidential information. Please let
> me know what you would prefer.
>
> Thank you very much.
>
> Noah Mendelsohn
> For the W3C Technical Architecture Group
>
> [1] http://www.w3.org/2001/tag/2011/06/06-minutes.html#item02
> [2] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0083.html
> [3]
> http://delivery.acm.org/10.1145/2080000/2071893/p40-gettys.pdf?ip=146.115.66.224&acc=OPEN&CFID=78529281&CFTOKEN=40620254&__acm__=1326812344_a90ac6c94bc5fbbba599fda9ff0da640
> [4] http://www.w3.org/2001/tag/2012/01/06-minutes#item02 [5]
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1236.html
> [6] http://www.w3.org/wiki/Html-data-tf
> [7] http://www.w3.org/TR/html-data-guide/
> [8] http://www.w3.org/TR/microdata-rdf/
>