<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC6962   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6962.xml">
<!ENTITY RFC6698   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY RFC2119   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4033   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4035   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC4034   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC6066   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
<!ENTITY RFC6024   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6024.xml">
<!ENTITY RFC6973   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.xml">
<!ENTITY RFC4251   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml">
<!ENTITY RFC5280   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">

<!ENTITY RFC5386   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5386.xml">
<!ENTITY I-D.ietf-websec-key-pinning PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-websec-key-pinning.xml">
<!ENTITY I-D.perrin-tls-tack PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.perrin-tls-tack.xml">
<!ENTITY RFC3280   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3280.xml">
]>


<rfc category="info" docName="draft-tschofenig-iab-webpki-evolution-01.txt"
     ipr="trust200902">
       
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc rfcedstyle="yes" ?>
  <?rfc subcompact="no"?>
  <?rfc compact="no"?>
  <?rfc strict="no"?>
  <front>

    <title abbrev="WebPKI Evolution">Evolving the Web Public Key Infrastructure</title>
    
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>IAB Security Program</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <code> </code>
          <country> </country>
        </postal>
        <email>Hannes.Tschofenig@gmx.net</email>
      </address>
    </author>
<!--	<author initials="R." surname="Housley" fullname="Russ Housley">
      <organization>IAB Security Program</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <code> </code>
          <country> </country>
        </postal>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <author initials="L." surname="Lynch" fullname="Lucy Lynch">
      <organization>IAB Security Program</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <code> </code>
          <country> </country>
        </postal>
        <email>lynch@isoc.org</email>
      </address>
    </author>
	 <author initials="K." surname="O'Donoghue" fullname="K. O'Donoghue">
      <organization>IAB Security Program</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <code> </code>
          <country> </country>
        </postal>
        <email>odonoghue@isoc.org</email>
      </address>
    </author>
  --> 
	 <author initials="E." surname="Lear" fullname="Eliot Lear">
      <organization>IAB Security Program</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <code> </code>
          <country> </country>
        </postal>
        <email>elear@cisco.com</email>
      </address>
    </author>
	
    <date year="2013"/>
    <area>Internet Architecture Board</area>
    <workgroup></workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>The problems with the WebPKI have received the attention by the Internet security community when DigiNotar, a Dutch certification authority, had a security breach in 2011 and in the same year a Comodo affiliate was compromised. Both cases led to fraudulent issuance of certificates and raise questions regarding the strength of the WebPKI used by so many applications.</t>

	  <t>Almost 2 years have passed since these incidents and various standardization activities have happened in the meanwhile offering new technical solutions to make the public key infrastructure more resilient.</t>

      <t>The important question, however, is which of the technical solutions will get widespread deployment? In this document we compare the different technical solutions in an attempt to engage the impacted stakeholders to trigger deployment actions to improve the status quo. This document does not include any recommendations what techniques to use.</t>
    </abstract>
  </front>
  <middle>

    <section anchor="intro" title="Introduction">
      <t>High-profile data breaches and security incidents on the Web are gaining increasing attention from the public, the press, and governments. A few examples may illustrate the problems: DigiNotar, a Dutch certification authority, had a security breach <xref target="DigiNotar"/> and in the same year a Comodo affiliate was compromised <xref target="Comodo"/>. Both cases led to fraudulent issuance of certificates.</t>

      <t>The Web Public Key Infrastructure (WebPKI) makes use of trusted third parties, the certification authority (CAs), to bind a subject name to a public key. A CA may, however, be compromised despite the best security practices and operational procedures. The main problem, however, is that any CA can issue a certificate for any domain name. One compromised CA is therefore able to impact the security of the entire public key infrastructure. In the case of DigiNotar the attacker was able to issue certificates for Google services even though Google never made use of services from DigiNotar.</t>

      <t>Furthermore, over time browser vendors and operating systems increased the number of trust anchors (TAs) that are pre-installed. Depending on software the number of trust anchors may exceed 600, as reported by the Electronic Frontier Foundation (EFF) in their SSL Observatory study <xref target="SSL-Observatory"/>. While the larger number provides choice for subjects regarding the CA they can select for obtaining a certificate there is also a downside: with today's WebPKI set-up it is sufficient to compromise a single CA to impact the security for all relying parties. Many users were surprised about the large number of trust anchors installed in normal operating systems and browsers without having an easy way to adjust that list to their preferences. Worse, most end users would not know what criteria to use to manage the trust anchor stores, even with better interfaces.</t>
	  
	  <t>To re-state the problem statement: Every CA can issue certificates for any relying party even though that relying party may have never been in a relationship with the issuing CA. (Note that the trust anchor of that CA needs to be provisioned into the trust anchor store.)</t>

	  <t>These developments have led to a number of protocol design activities for improving the WebPKI. In this document we briefly summarize the available technical solutions and include an assessment about who needs to make changes, what type of benefits are provided, and what dependencies exist. The investigated solutions include DANE <xref target="RFC6698"/>, Certificate Transparency <xref target="RFC6962"/>, Public Key Pinning 
	  <xref target="I-D.ietf-websec-key-pinning"/>, TACK <xref target="I-D.perrin-tls-tack"/>, Perspectives <xref target="Perspectives"/>, Sovereign Keys <xref target="SovereignKeys"/>, MECAI <xref target="MECAI"/>, Convergence <xref target="Convergence"/>, and DetecTor <xref target="DetecTor"/>.</t> 
	  
	  <t>There are many challenges with security on the Web, including user interface problems with certificate warnings, insecure use of cookies, cross-site scripting attacks, and injection attacks. This document focuses only on improving the WebPKI. It is also worth reminding ourselves that the WebPKI is not only used for Web applications but also for a range of other applications, including smart phone apps. <!-- Furthermore, other public key infrastructures that operate under a different regime with different policies may suffer from similar problems. Consequently, the solution techniques discussed in this document are also useful for these other PKI deployments.--> </t>
	  
	  <t>The main purpose of this document is to provide an overview of some technical solutions. This description will help us to develop a roadmap for the deployment of the best solutions to improve the overall security of the public key infrastructure.</t>
	  
	  <t>Final note: There are also process solutions, such as stricter audits of CAs with the aim to improve operational practices, and these are not described in this document. These measures will be useful in addition to technical solutions but alone they will, however, not address the underlying problem.</t>
	</section> 
	
	<section anchor="terms" title="Terminology">
	<t>This document uses the following terms from from RFC 5280 <xref target="RFC5280"/>:
	<list style="hanging">
	   <t hangText="end entity:">user of PKI certificates and/or end user system that is
               the subject of a certificate.</t>
	   <t hangText="CA:">certification authority</t>
	   </list> 
	</t>
	
	<t>This document also re-uses the term "Leap of faith" from RFC 5386 <xref target="RFC5386"/>:
	
	<list style="empty">
	<t>"Leap of faith is the term generally used when a user accepts the
   assertion that a given key identifies a peer on the first
   communication (despite a lack of strong evidence for that assertion),
   and then remembers this association for future communications."</t>
   <t>This security property has become fairly popular with use of Secure Shell
   <xref target="RFC4251"/>, which made use of the leap of faith property.</t>
   </list> 
   </t>
   
   <t>RFC 6973 <xref target="RFC6973"/> provides a definition of the term 'relying party':
   <list style="empty">
	<t>"The relying party is an entity that relies on assertions of individuals'
      identities from identity providers in order to provide services to
      individuals. In effect, the relying party delegates aspects of
      identity management to the identity provider(s).  Such delegation
      requires protocol exchanges, trust, and a common understanding of
      semantics of information exchanged between the relying party and
      the identity provider."
	  </t>
	  <t>In the context of this document the relying party is a TLS client, for example, used to protect the communication from a Web server. Although a lot of focus is on the Web there are other non-HTTP-based services that are included in the definition and may benefits from improvements discussed in this document.</t>
	</list> 
	</t>
	
	<t>The terms 'trust anchor' and 'trust anchor store' are defined in <xref target="RFC6024"/>:
	<list style="empty">
	<t>"A trust anchor represents an authoritative entity via
      a public key and associated data.  The public key is used to
      verify digital signatures, and the associated data is used to
      constrain the types of information for which the trust anchor is
      authoritative."</t>
	  
	<t>"A trust anchor store is a set of one or more
      trust anchors stored in a device. A device may have
      more than one trust anchor store, each of which may be used by one
      or more applications."</t> 
	</list>
	</t>
	</section> 
	
	<section anchor="solutions" title="Technical Solutions">
	  
	  <section anchor="key-pinning" title="Public Key Pinning for HTTP">
	    <t><xref target="I-D.ietf-websec-key-pinning"/> describes a solution for instructing user agents (UAs) to remember ("pin") certificates (end entity certificates or CA certs) for a given period of time. This pin is provided to the client with the initial interaction with a Web server using a newly defined HTTP headers. During that time, UAs will require that the TLS server presents a certificate chain including at least one Subject Public Key Info structure the fingerprint of which matches one of the pinned fingerprints for that server.</t>
		
		<t>While the specification provides a number of instructions for the Website operator the basic operation is rather simple and assumes a leap-of-faith policy. To deal with the change of certificates or other failure scenarios, the concept of a backup pin is utilized.  A Backup Pin is a fingerprint for the public key of a secondary, not-yet-deployed key pair.  The operator keeps the backup key pair offline, and sets a pin for it in the Public-Key-Pins header.  If an operator loses control of his/her
   primary private key, he/she can deploy the backup key pair. An interesting feature of the specification is to report pin validation failure to a URI using an HTTP POST.</t>
   
        <t>When a pin validation failure occurs the expectation is that the user is notified about the inconsistency (with optionally reporting taking place in the background).</t> 
		
		<t>This document is the product of the IETF Web Security working group.</t>
	  </section> 
	  
	  <section title="Trust Assertions for Certificate Keys (TACK)">
	  
	  <t>Similarly to the key pinning solution described in <xref target="key-pinning"/> TACK <xref target="I-D.perrin-tls-tack"/>, also aims to enables a TLS server to support "pinning" to a self-chosen signing key.</t>
   
   <t>A TLS server operator creates a so-called "TACK signing key" (TSK) and signs its own keys using this TSK. A TACK pin then associates a hostname, a TSK, and various parameters (including pin creation time, and lifetime of the pin). A TLS server operator may change a key for a server at any point in time since the TSK will be unchanged. Each server thereby acts as its own CA and issues end entity certificates to itself. Clients store the TACK pins in their pin stores, which they obtain via a TLS extension from the server directly. When TACK pins are obtained from the TLS server directly, they follow a leap-of-faith approach.</t>
   
   <t>To enable incremental deployment, a TLS client uses the extension mechanism of TLS to indicate support for the TACK extension by including a new TLS extension type in the ClientHello message. A TLS server that does not support TACK will reply with an ordinary certificate. In case the TLS server supports the extension it replies with the newly defined tack structure, which contains the TACK pin for that server.</t>
   
   <t>This specification is an individual submission to the IETF.</t>	  

<!-- 
   <t>[Editor's Note: The document claims that the proposal also works with certificates. However, details are missing to describe how the TLS server key is signed with the TSK and then used by a regular TLS library.]</t>
--> 

	  </section> 
	  
	  <section title="Perspectives">
	  
	  <t>Perspectives <xref target="Perspectives"/> aims to utilize notaries (i.e., public servers) that monitor and record the history of public keys used by services. 
	  A notary cryptographically signs statements saying that at time t it observed service S using public key K. While the description focuses on the use of raw public keys (in the style of SSH) the same concept also works with certificates.</t>
	  
	  <t>The basic approach is simple: When a TLS client starts to interact with a TLS server it is presented with a key/certificate that it had not seen before. To verify that the key/certificate is the same as observed by other vantage points in the network it contacts notary servers. These notaries provide key/certificate information they have obtained about the specific website earlier. Subsequently, clients cache the information returned by notaries for future use.</t>
	  
	  <t>Since the security and availability of the proposed system depends on the location, the independence, and the number of notaries the following approach is suggested. Notaries are organized in groups, each group having a notary authority. The notary authority publishes lists of the notaries it offers. These lists contain entries with IP address information and their public keys, one for each notary. This list is then digitally signed with the private key of the notary authority. Clients are expected to download these lists and verify them with the public key of the respective notary authority. The public keys of the notary authorities are obtained out-of-band.</t>
	  

      <t>To improve the leap of faith security by clients, the notary services adds security value since they may have obtained the key/certificate from the website in the past already and from different vantage points (in terms of the path used to talk to the server). This helps when attacks are either temporary and or when a man-in-the-middle attacker is located somewhere along the path between the client and the server but closer to the client. The use of multiple notaries also helps to detect malicious notaries.</t>	  
	  
	  <t>Similar to other notary services there is the question about how they obtain the keys/certificates of TLS servers (and other services). For popular services the keys/certificates are assumed to pre-configured at the notaries and queried periodically. For the long tail of small websites the suggested approach is to query these sites the first time a client wants to connect to them since this is the time when the notary learns about their existence.</t> 

	  <t>With clients caching information about the keys/certificates of sites visited earlier, and the information obtained from notaries, there is no additional protocol overhead. In this respect the solution works similar to key pinning. The additional communication overhead for the client only occurs at the time when the client talks to a server for the first time or when the cached information expires.</t>
	   
	  <t>The proposal is documented in form of an academic research paper, see <xref target="Perspectives"/>, but no technical specification is available.</t>
	  </section> 
	  
	      <section title="Convergence">
	   <t>Convergence <xref target="Convergence"/> is a proposal by Moxie Marlinspike that makes two improvements to Perspectives, namely  
	   
	   <list style="hanging"> 
	   <t hangText="Reducing Notary Lag:">The Perspectives solution required TLS clients to interact with notaries to check whether a certificate obtained via TLS matches the information seen notaries. Notaries then had to initiate an interaction with the TLS servers to obtain information about what certificates they see. Convergence reduces this interaction by utilizing caching of certificates at the notaries. By doing this, however, they also introduce a delay between the time a new certificate is put in operation at a TLS server and when the notaries get to learn about it.</t>
	   <t hangText="Increased Privacy Protection:">First, clients cache certificates so that they do not need to contact notaries every time they contact a Web site. Second, clients use a concept called 'notary bouncing' whereby they pick a notary randomly out of their pool of trusted notaries and use it as a proxy to talk to other notaries. Thereby, the notary that receives the query will only see the IP address of another notary who forwarded the query rather than the IP address of the client.</t>
	   </list> 
	   </t>	  
	   
	   <t><!-- The client can decide how many notaries are consulted to obtain certificate from a given TLS servers. -->As a main advantage, according to the author and similar to Perspectives, there is no impact on TLS server deployment, except in rare situations where multiple certificates are used by a single site in combination with a load balancer. Load balancers often terminate TLS connections and if those load balancers use independent certificates then different notaries requesting certificates from the Web site will receive different certificates.</t>
	   
	   <t>Notaries are designed to be extensible by supporting different mechanisms with respect to how they obtain certificates. Currently, Convergence uses the technique proposed by Perspectives to probe a TLS server. </t>
	   
	   <t>The documentation of Convergence only exists in form of a presentation by Moxie Marlinspike given at the BlackHat USA 2011 conference <xref target="ConvergenceTalk"/>.</t>
	  </section> 
	  
	  
	  <section title="Sovereign Keys">
	  
	   <t>Sovereign Keys <xref target="SovereignKeys"/> is a proposal by the Electronic Frontier Foundation (EFF). It introduces two new concepts to deal with attacks against the WebPKI.

<list style="hanging"> 
<t hangText="Sovereign key:">Each domain owner creates a new key pair, the sovereign
      keys, and use the private key to sign its operational (EE) certificates or  
      public keys.

</t>
<t hangText="Timeline servers:">Append-only timeline servers, as new entities, are introduced. They stores mappings between domain names and sovereign keys. To claim a key for a domain name requires evidence of control in the DNS either via a CA-signed certificate or via a key published in the DNS (as provided by DANE).</t>
</list> 
</t>

	   <t>Each timeline server possesses a unique private/public key pair and these keys are assumed to be shipped with client software or TLS libraries to ensure that clients can verify the authenticity of timeline entries. The timeline servers record the history of claims to sovereign keys.
	   </t>
  
       <t>TLS clients query timeline servers for entries that belong to a certain domain and verify that the end-entity certificate has been issued under the sovereign key. If the verification fails then the connection attempt is refused. <!-- For example, if the domain owner of example.org uses DANE to store a self-signed signed certificate then a TLS client connecting to a Web server at https://example.org would first obtain the sovereign key of example.org from a timeline server. It would verify the response from the timeline server using the pre-provisioned keys.--> </t>
	   
	   <t>A high-level description can be found at <xref target="SovereignKeys"/> and a more detailed technical specification is available at <xref target="SovereignKeys-Spec"/>.</t>
	   </section> 
	 
	  <section title="Mutually Endorsing CA Infrastructure (MECAI)">
	  
	  <t>MECAI <xref target="MECAI"/> builds conceptually on top of the Perspective proposal. Perspectives introduces notaries, as new entities in the WebPKI, and MECAI takes the position that this function can be taken by existing CAs. With this new role they would turn into Voucher Authorities (VAs), who issue vouchers that confirm what they observe. A voucher is a signature computed over a number of fields including the hash of a server certificate, a certificate chain, the IP address of the server, revocation status information, etc. Of course, a voucher would be created by a CA other than the one that created the original certificate.</t>
	  
	  <t>A client would therefore perform the following steps: it connects to a server via TLS and the server provides the certificate. Then, the client needs to obtain one or multiple vouchers for the server certificate. This can happen either inband within the TLS handshake when talking to the server, similarly to how OCSP stapling works, or via a separate protocol exchange. The former approach is less expensive in terms of communication costs for the client. In any case, a voucher request protocol is needed to let entities (like TLS servers) talk to VAs to obtain a voucher.</t>
	  
	  <t>A client or a server can detect misissuance by matching the information in the vouchers with the certificate.</t>
	  
	  <t>Only a high-level description is available via <xref target="MECAI"/> but no detailed technical specification.</t>
	  </section>
	 
	
	  <section title="DNS-Based Authentication of Named Entities (DANE)">
	    <t>DANE <xref target="RFC6698"/> offers the option to use the DNS infrastructure to store certificates. DANE is envisioned as a preferable basis for binding public keys to DNS names, because the entities that vouch for the binding of public key data to DNS names are the same entities responsible for managing the DNS names in question.</t>
   
   <t>Distributing certificates via the DNS does, however, require DNSSEC. With the help of DNSSEC <xref target="RFC4033"/><xref target="RFC4034"/><xref target="RFC4035"/> this offers an opportunity to eliminate off-line processes for validation of the subject name, which today often requires sending a mail to the administrator of that domain. This relationship can be easily demonstrated by having the zone administrator for the subject domain post the public key in the DNS and digitally sign the resulting zone.</t>

   <t>A high-level description about the different options offered by DANE can be found in <xref target="IETF-Journal-DANE"/> and the authoritative version can be found in RFC 6698 <xref target="RFC6698"/>.</t>
   
	  </section> 
	  
	  <section title="Certificate Transparency"> 
	    <t>RFC 6962 <xref target="RFC6962"/> specifies Certificate Transparency, a protocol for publicly logging the existence of certificates as they are issued or observed. This allows anyone to audit
   certification authority (CA) activity and detect the issuance of suspect certificates, as well as to audit the certificate logs themselves.  The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.</t>	

   <t>The publicly auditable, append-only logs of all issued certificates does not prevent misissue but allows interested parties to detect misissuance.</t>

   <t>While various projects, including the EFF with their SSL Observatory <xref target="SSL-Observatory"/> and Crossbear <xref target="Crossbear"/>, have scanned the Internet to collect all certificates of publically accessible TLS servers, the cooperation from all TAs (and subordinate CAs) is required to make Certificate Transparency proposal successful. The reasons are two-fold: IPv6 makes scanning the address range of the entire Internet much more difficult and the increasing deployment of the TLS Server Name Indication <xref target="RFC6066"/> prevents it from obtaining all certificates.</t>
   
   <t>The expected operation is as follows: TA and subordinate CAs 
   contact log servers and upload certificates, as they are issued.  
 In response, they receive a Signed Certificate Timestamp (SCT). The SCT is the log's promise to incorporate the certificate in a Merkle Tree, which is the data structure used by the log, within a fixed amount of time. Everyone can check the log for consistency. Website operators will have an incentive to regularly check the logs for misissuance of certificates issued to DNS names associated with their sites. TLS clients on the other hand are not expected to directly communicate with logs to avoid the communication overhead. Instead, the TLS servers provides the SCT along with the certificate within the TLS handshake. TLS clients reject certificates that do not have a valid SCT for the end entity certificate. Since there is ideally more than one log TLS servers need to provide SCTs from multiple logs to the client.</t>
   
<t>This document has gone through a public review process, and has been approved by the Internet Engineering Steering Group and published an experimental RFC.</t>

	  </section> 
	  
	  
	  <section title="DetecTor">
	  
	   <t>DetecTor <xref target="DetecTor"/> extends the idea of MECAI and Perspectives by utilizing the Tor onion routing infrastructure <xref target="Tor"/> in order to connect to sites via different paths through the network. The Tor infrastructure thereby replaces the need to have dedicated notary servers, who connect to sites to obtain certificates from a different vantage point. The server certificate obtained via one or multiple Tor connections is then compared with the certificate that was obtained via the direct TLS connection between the client and the site (i.e., without using Tor). This offers capabilities for the client to detect whether there was an adversary along the path but close to the client. </t>
	  
	  <t>Unlike other proposals, the suggestion is made to provide no information to the user once a failure has been detected. Instead, the connection attempt will be rejected and no recourse is possible. Like other proposals information about the observed certificates may be cached by the client to lower the initial set-up delay.</t>
	  
      <t>A high-level description can be found at <xref target="DetecTor"/> but no detailed technical specification is available.</t>

	  </section> 
	  
	     
    <!-- 
	    <section title="Crossbear">
	  
	   <t>Crossbear <xref target="Crossbear"/> </t>
	  
	  </section> 
	-->   
	    
	
	  
	 <!-- 
	    <section title="HTTPS Everywhere">
	   <t>HTTPS Everywhere <xref target="HTTPS-Everywhere"/> is the result of a collaboration between The Tor Project and the Electronic Frontier Foundation. Although the main focus of the project is to increase the use of TLS with Web sites, which is only loosely related to the scope of this document it also provides  </t>	  
	  </section> 
	  -->  
	  
	  
	</section> 
	  
	  
	  
    <section anchor="analysis" title="Analysis">
      <t>This version of the document re-uses the analysis criteria proposed by Eric Rescorla <xref target="Rescorla"/>.</t>
	 
	  <section title="Public Key Pinning for HTTP">
	  <t><list style="hanging">
	  <t hangText="Changes Needed:">Browsers, Servers</t>
<t hangText="Benefits:">Prevention and Detection (when reporting is used)</t>
<t hangText="Dependencies:">None</t>
<t hangText="Incremental Deployment:">Newly added server can make use of the technology when browsers have been updated. Works with existing WebPKI infrastructure.</t>
<t hangText="Risks:">Employs a leap of faith concept. Self-DoS if pins are configured incorrectly.</t>
	  </list></t>
	  </section> 
	  
	  
	  <section title="Trust Assertions for Certificate Keys (TACK)">
	  <t><list style="hanging">
	  <t hangText="Changes Needed:">Browsers, Servers</t>
<t hangText="Benefits:">Prevention</t>
<t hangText="Dependencies:">Requires server operators to create and manage new public / private key pair (TSK)</t>
	    <t hangText="Incremental Deployment:">A newly deployed server can make use of the technology when browsers have been updated. Does not seem to work with existing WebPKI.</t>
	    <t hangText="Risks:">Employs a leap of faith concept.</t>
	  </list></t>
	    
	    
	  </section> 
	  
	  <section title="Perspectives">
	  <t><list style="hanging">
	   <t hangText="Changes Needed:">Third party infrastructure (notaries), Clients</t>
	    <t hangText="Benefits:">Prevention</t>
<t hangText="Dependencies:">Requires notaries to be deployed.</t>
<t hangText="Incremental Deployment:">Once notaries are available and client
      software is updated, the solution works for every server.
</t>
<t hangText="Risks:">Increased communication overhead for contacting notaries and waiting notaries to check servers. Potential problems when load balancers are deployed at the server infrastructure.</t>
	  </list></t>
	    
	    
	  </section> 
	  
	  <section title="Convergence">
	  <t><list style="hanging">
	    <t hangText="Changes Needed:">Third party infrastructure (notaries), Clients</t>
	    <t hangText="Benefits:">Prevention</t>
	    <t hangText="Dependencies:">Requires notaries to be deployed.</t>
	    <t hangText="Incremental Deployment:">Once notaries are available and client software is updated, the solution works for every server.</t>
	    <t hangText="Risks:">Increased communication overhead for contacting notaries and for letting notaries check servers (although more extensive caching is utilized than with Perspectives). The notary bounding concept may introduce additional latency. Potential problems when load balancers are deployed at the server infrastructure. With caching, a delay may be introduced between the time when a new server certificate is configured and the time when the notaries notice about its existence, resulting in false alarms.</t>
	  </list></t>
	    
	  </section> 
	  
	  
	  <section title="Sovereign Keys">
	  <t><list style="hanging">
	    <t hangText="Changes Needed:">Third party infrastructure (timeline), Clients, Servers</t>
<t hangText="Benefits:">Prevention</t>
	    <t hangText="Dependencies:">Requires server operators to create and manage a new public / private key pair (sovereign key). Requires third party infrastructure (timeline servers).</t>
	    <t hangText="Incremental Deployment:">Server operators will receive benefits once timeline servers are deployed, and updates to the client software have been made.</t>
	    <t hangText="Risks:">Increased communication overhead for contacting timeline servers. </t>
	  </list></t>
	    
	  </section> 
	  
	  <section title="Mutually Endorsing CA Infrastructure (MECAI)">
	  <t><list style="hanging">
	    <t hangText="Changes Needed:">CAs (who operate as Voucher Authorities (VAs)), Servers, Clients</t>
<t hangText="Benefits:">Prevention</t>
<t hangText="Dependencies:">Requires CAs to operate VAs</t>
<t hangText="Incremental Deployment:">Requires at least two CAs to support MECAI before TLS servers can start to offer vouchers in the TLS handshake to clients for verification.</t>
<t hangText="Risks:">A VA has to obtain a certificate and verify it before it can issue a voucher. A client may request vouchers from a number of VAs, via an extension within the TLS handshake, to have increased confidence.</t>
	  </list></t>
	  </section> 
	  
	  <section title="DNS-Based Authentication of Named Entities (DANE)">
	  <t><list style="hanging">
	  <t hangText="Changes Needed:">Clients, Server's DNS</t>
<t hangText="Benefits:">Prevention</t>
<t hangText="Dependencies:">DNSSEC deployment at clients, and intermediaries.</t>
<t hangText="Incremental Deployment:">
A new server can add support for DANE only if its DNS server operator allows TLSA records to be added and secured via DNSSEC. Clients require software support in the browsers for verifying the DNSSEC protected TLSA record.

</t>
<t hangText="Risks:">Self-DoS with incorrect TLSA records, false positives with broken intermediaries, lack of DNSSEC deployment or failure of DNSSEC validation.</t>
	  </list></t>
	  </section> 
	  
	  <section title="Certificate Transparency">
	  <t><list style="hanging">
	   <t hangText="Changes Needed:">Third party infrastructure (notaries), CA, Clients. Servers do not need to change when the SCT is
incorporated in the cert by the CA.</t>
<t hangText="Benefits:">Detection</t>
<t hangText="Dependencies:">Requires notaries and all CAs to participate</t>
<t hangText="Incremental Deployment:">CAs and servers who want to deploy the infrastructure can start deployment.</t>
<t hangText="Risks:"><!-- Non-participating CAs are not monitored and attacks against those cannot be detected.--> 

Certificates without an accompanying SCT are not accepted. Hence, all
relevant certs are necessarily monitored (even non-participating CAs
may be partially monitored if their customers use updated servers that
do CT).
</t>
	  </list></t>
	  </section> 
	  
	  <section title="DetecTor">
	  <t><list style="hanging">
	   <t hangText="Changes Needed:">Clients</t>
<t hangText="Benefits:">Prevention</t>
<t hangText="Dependencies:">Depends on Tor infrastructure</t>
<t hangText="Incremental Deployment:">With client-side only changes all servers can be verified.</t>
<t hangText="Risks:">Setup delay and sites that utilize load balancers. Relies on leap-of-faith security. Server certificate changes might cause mismatches with cached information.</t>
	  </list></t>
	  </section> 
	  
      <section title="Limitations">
        <t>A common problem of all proposals that aim to prevent attacks lies in the user interface design when a failure occurs and end users are informed about the problem. In many cases, the failure may not necessarily be caused by real attacks but rather by the use of captive portals or server-side configuration problems (like warnings caused by expired certificates today). User interface studies, such as <xref target="SE09"/>, <xref target="SR07"/>, and <xref target="BO09"/>, have shown that end users are typically not in the best position to make judgments  about these security warning dialogs. Furthermore, proposals that make use of out-of-band communication interactions may face problems with firewalled networks and the additional delay incurred. Claims have been made that this is a problem with the use of OCSP today <xref target="OCSP-Performance"/>, which has been the motivation for developing and standardizing OCSP stapling and multiple OCSP stapling.</t>
      </section>
      
    </section>
	  
	 
	
    <section anchor="security" title="Security Considerations">
      <t>This entire document is about security.</t>
    </section>

	
    <section anchor="privacy" title="Privacy Considerations">
      <t>The main privacy threat is correlation. Correlation is the combination of various pieces of information
   related to an individual or that obtain that characteristic when combined. In this specific case there is the risk that newly introduced entities obtain information about the history of service usage by users. For example, a notary that is contacted each time a user visits a new website can easily be seen as problematic from a privacy point of view.</t>
    </section>
	
    <section anchor="iana" title="IANA Considerations">
       <t>This document does not require actions by IANA.</t>
    </section>

    <section title="Acknowledgements">
      <t>We would like to thank all participants of the NIST workshop on "Improving Trust in the Online Marketplace", April 10-11 2013, for sharing their views with the community. We would also like to thank the authors of various solution proposals for their work.</t>
      
      <t>Big thanks to Steven Kent for his detailed review. Additionally, we would like to thank Ben Laurie for his feedback.</t> 
    </section>

  </middle>
  <back>
    <references title="Normative References"> 
	<!-- &RFC2119; --> 
	&RFC6962;
    &RFC6698;
	&RFC4033; 
	&RFC6066; 
	&RFC5280; 
	&RFC4034; 
	&RFC4035;
    &I-D.ietf-websec-key-pinning;
	&RFC3280;
    &I-D.perrin-tls-tack;
	
	
	      <reference anchor="SovereignKeys">
        <front>
          <title>The Sovereign Keys Project</title>
  <author>
		  <organization>EFF</organization>
		  </author>

          <date month="Oct" year="2013" />
        </front>

        <seriesInfo name=""
                    value="URL: https://www.eff.org/sovereign-keys" />

        <format target="https://www.eff.org/sovereign-keys"
                type="HTML" />
      </reference>
	  
	       <reference anchor="SovereignKeys-Spec">
        <front>
          <title>Sovereign Key Cryptography for Internet Domains</title>

          <author fullname="Peter Eckersley" initials="P." surname="Eckersley"></author>

          <date month="Oct" year="2013" />
        </front>

        <seriesInfo name=""
                    value="URL: https://git.eff.org/?p=sovereign-keys.git;a=blob;f=sovereign-key-design.txt;hb=master" />

        <format target="https://git.eff.org/?p=sovereign-keys.git;a=blob;f=sovereign-key-design.txt;hb=master"
                type="HTML" />
      </reference>
	
	       <reference anchor="Convergence">
        <front>
          <title>Convergence</title>
          <author fullname="Moxie Marlinspike" initials="M." surname="Marlinspike"></author>
          <date year="2013" />
        </front>

        <seriesInfo name=""
                    value="URL: http://convergence.io" />

        <format target="http://convergence.io"
                type="HTML" />
      </reference>

	    <reference anchor="ConvergenceTalk">
        <front>
          <title>BlackHat USA 2011: SSL And The Future Of Authenticity</title>
          <author fullname="Moxie Marlinspike" initials="M." surname="Marlinspike"></author>
          <date year="2013" />
        </front>

        <seriesInfo name=""
                    value="URL: http://www.youtube.com/watch?v=Z7Wl2FW2TcA" />

        <format target="http://www.youtube.com/watch?v=Z7Wl2FW2TcA"
                type="HTML" />
      </reference>
	  
	  <reference anchor="Perspectives">
        <front>
          <title>Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing</title>

          <author fullname="Dan Wendlandt" initials="D." surname="Wendlandt"></author>
          <author fullname="David Andersen" initials="D." surname="Andersen"></author>
          <author fullname="Adrian Perrig" initials="A." surname="Perrig"></author>


          <date year="2008" />
        </front>

        <seriesInfo name=""
                    value="URL: http://www.cs.cmu.edu/~dga/papers/perspectives-usenix2008/" />

        <format target="http://www.cs.cmu.edu/~dga/papers/perspectives-usenix2008/"
                type="HTML" />
      </reference>
   
    <reference anchor="MECAI">
        <front>
          <title>MECAI - Mutually Endorsing CA Infrastructure</title>

          <author fullname="Kai Engert " initials="K." surname="Engert"></author>

          <date month="Feb" year="2012" />
        </front>

        <seriesInfo name=""
                    value="URL: https://kuix.de/mecai/" />

        <format target="https://kuix.de/mecai/"
                type="HTML" />
      </reference>
    
	
    <reference anchor="DetecTor">
        <front>
          <title>DetecTor</title>

          <author fullname="Kai Engert " initials="K." surname="Engert"></author>

          <date month="Sep" year="2013" />
        </front>

        <seriesInfo name=""
                    value="URL: http://detector.io" />

        <format target="http://detector.io"
                type="HTML" />
      </reference>
	</references>
	
    <references title="Informative References"> 
	
	&RFC5386; &RFC4251;
	
     <reference anchor="DigiNotar">
        <front>
          <title>DigiNotar SSL certificate hack amounts to cyberwar, says expert</title>

          <author fullname="Charles Arthur" initials="C." surname="Arthur"></author>


          <date month="Sep" year="2011" />
        </front>

        <seriesInfo name=""
                    value="URL: http://www.guardian.co.uk/technology/2011/sep/05/diginotar-certificate-hack-cyberwar" />

        <format target="http://www.guardian.co.uk/technology/2011/sep/05/diginotar-certificate-hack-cyberwar"
                type="HTML" />
      </reference>
	  
	    <reference anchor="Comodo">
        <front>
          <title>The Recent RA Compromise</title>

          <author fullname="Phillip Hallam-Baker" initials="P." surname="Hallam-Baker"></author>


          <date month="Mar" year="2011" />
        </front>

        <seriesInfo name=""
                    value="URL: http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/" />

        <format target="http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/"
                type="HTML" />
      </reference>
   
     <reference anchor="SSL-Observatory">
        <front>
          <title>The EFF SSL Observatory</title>

          <author>
		  <organization>EFF</organization>
		  </author>


          <date month="Oct" year="2013" />
        </front>

        <seriesInfo name=""
                    value="URL: https://www.eff.org/observatory" />

        <format target="https://www.eff.org/observatory"
                type="HTML" />
      </reference>
	  
	    <reference anchor="IETF-Journal-DANE">
        <front>
          <title>DANE: Taking TLS Authentication to the Next Level Using DNSSEC, IETF Journal</title>

          <author fullname="Richard Barnes" initials="R." surname="Barnes"></author>


          <date month="Oct" year="2011" />
        </front>

        <seriesInfo name=""
                    value="URL: http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec" />

        <format target="http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec"
                type="HTML" />
      </reference>
   
   
     
	  
	      <reference anchor="Tor">
        <front>
          <title>Tor - Anonymity Online</title>
  <author>
		  <organization>The Tor Project</organization>
		  </author>

          <date month="Oct" year="2013" />
        </front>

        <seriesInfo name=""
                    value="URL: https://www.torproject.org/" />

        <format target="https://www.torproject.org/"
                type="HTML" />
      </reference>
	  
<!-- 
	       <reference anchor="HTTPS-Everywhere">
        <front>
          <title>HTTPS Everywhere</title>

          <author>
		  <organization>EFF</organization>
		  </author>


          <date month="Oct" year="2013" />
        </front>

        <seriesInfo name=""
                    value="URL: https://www.eff.org/https-everywhere" />

        <format target="https://www.eff.org/https-everywhere"
                type="HTML" />
      </reference>
--> 
	
	
	 <reference anchor="Crossbear">
        <front>
          <title>Crossbear</title>

          <author>
		  <organization>Technical University Munich</organization>
		  </author>


          <date month="Oct" year="2013" />
        </front>

        <seriesInfo name=""
                    value="URL: https://pki.net.in.tum.de/" />

        <format target="https://pki.net.in.tum.de/"
                type="HTML" />
      </reference>
	  
	  <reference anchor="SE09">
        <front>
          <title>Crying Wolf: An Empirical Study of SSL Warning Effectiveness, 18th USENIX Security Symposium</title>

          <author fullname="Joshua Sunshine" initials="J." surname="Sunshine"></author>

          <author fullname="Serge Egelman" initials="S." surname="Egelman"></author>

          <author fullname="Hazim Almuhimedi" initials="H." surname="Almuhimedi"></author>

          <author fullname="Neha Atri" initials="N." surname="Atri"></author>

          <author fullname="Lorrie Faith Cranor" initials="L." surname="Cranor"></author>

          <date month="Aug" year="2009" />
        </front>

        <seriesInfo name=""
                    value="URL: http://lorrie.cranor.org/pubs/sslwarnings.pdf" />

        <format target="http://lorrie.cranor.org/pubs/sslwarnings.pdf"
                type="PDF" />
      </reference>
	  
	   <reference anchor="BO09">
        <front>
          <title>Browser Interfaces and Extended Validation SSL Certificates: An Empirical Study, Proceedings of the 2009 ACM workshop on Cloud computing security</title>

          <author fullname="Robert Biddle" initials="R." surname="Biddle"></author>

          <author fullname="Paul van Oorschot" initials="P." surname="van Oorschot"></author>

          <author fullname="Andrew Patrick" initials="A." surname="Patrick"></author>

          <author fullname="Jennifer Sobey" initials="J." surname="Sobey"></author>

          <author fullname="Tara Whalen" initials="T." surname="Whalen"></author>

          <date year="2009" />
        </front>

        <seriesInfo name=""
                    value="URL: http://www.andrewpatrick.ca/cv/Biddle-CCSW-2009.pdf" />

        <format target="http://www.andrewpatrick.ca/cv/Biddle-CCSW-2009.pdf"
                type="PDF" />
      </reference>
	  
	  
	  <reference anchor="SR07">
        <front>
          <title>The Emperor's New Security Indicators: An evaluation of website authentication and the effect of role playing on usability studies, The 2007 IEEE Symposium on Security and Privacy</title>

          <author fullname="Stuart Schechter" initials="S." surname="Schechter"></author>

          <author fullname="Rachna Dhamija" initials="R." surname="Dhamija"></author>

          <author fullname="Andy Ozment" initials="A." surname="Ozment"></author>

          <author fullname="Ian Fischer" initials="I." surname="Fischer"></author>

          <date month="May" year="2007" />
        </front>

        <seriesInfo name=""
                    value="URL: http://www.usablesecurity.org/emperor/" />

        <format target="http://www.usablesecurity.org/emperor/"
                type="HTML" />
      </reference>
	  
	  
	  <reference anchor="OCSP-Performance">
        <front>
          <title>Certificate revocation and the performance of OCSP</title>

           <author>
		  <organization>Netcraft</organization>
		  </author>
          <date month="Apr" year="2013" />
        </front>

        <seriesInfo name=""
                    value="URL: http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html" />

        <format target="http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html"
                type="HTML" />
      </reference>
	  
	  
	  
	  <reference anchor="Rescorla">
        <front>
          <title>Deployment Models for Backup Certificate Systems, NIST Workshop on Improving Trust in the Online Marketplace</title>

          <author fullname="Eric Rescorla" initials="E." surname="Rescorla"></author>

          <date month="Apr" year="2013" />
        </front>

        <seriesInfo name=""
                    value="URL: http://csrc.nist.gov/groups/ST/ca-workshop-2013/presentations/Rescorla_ca-workshop2013.pdf" />

        <format target="http://csrc.nist.gov/groups/ST/ca-workshop-2013/presentations/Rescorla_ca-workshop2013.pdf"
                type="PDF" />
      </reference>
	  
	  
	  
	  
	  &RFC6973;
      &RFC6024; 
	  
	
    </references>
  </back>
</rfc>
