Subject: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers

From: "trans issue tracker" <[email-masked]>
Date: Sat, 05 Dec 2015 07:40:08 -0000

#145: Section 9.2 (TLS clients) needs more guidance for browsers

 The WG discussions have focussed on browsers as the key TLS client and
 motivating use case.  So it might make sense for Section 9.2 (TLS Clients)
 to reflect this and focus on browsers. In particular, text needs to be
 added re: the role that browser vendors play and the section also needs to
 allow for added guidance for browsers. For example, saying that a TLS
 client MUST reject an SCT with a future timestamp does not provide clear
 direction for a browser on what to do with the certificate. One can argue
 that if an SCT is present and found to be invalid then a browser SHOULD
 treat the certificate as invalid. (This case is very different from having
 a browser treat a certificate as invalid because an SCT is not available,
 e.g., because of the incremental deployment issues associated with the
 latter.)

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  rfc6962-bis  |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/145>
trans <https://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 24 Dec 2015 02:50:32 -0000

Comment (by [email-masked]):

 Along the lines of
 [https://mailarchive.ietf.org/arch/msg/trans/kD72jFHiTzS3tSGU755byjNQOSM],
 I've come up with some text (to replace the current text in Section 9.2)
 that I think addresses the issues in this ticket while avoiding the use of
 standards language. This approach will hopefully make it easier for
 6962-bis to progress, without first requiring consensus on TLS client
 behavior.

     CT benefits a TLS client by providing additional confidence in the
 authenticity of a TLS server's certificate (if the certificate has been
 logged). A TLS client that is not CT-aware receives some of the benefit of
 CT due to normal revocation of mis-issued certificates that have been
 identified by other components of the CT system. However, a TLS client may
 receive additional benefits from CT if the client is CT-aware. (A TLS
 client is deemed to be CT-aware if it is configured with CT metadata that
 enables it to validate SCTs and other data signed by one or more logs).
 While CT could be applied to any TLS client, in practice it is designed
 primarily with web browsers in mind. As such, the remainder of this
 section discusses browsers.

     A browser benefits from CT most when the browser can verify that each
 TLS server certificate chain it relies on has been properly logged, and is
 thus available to Monitors. To do this, a browser will (indirectly)
 receive information from logs, potentially via the mechanisms specified in
 Section 7. The browser will then need to parse and verify that
 information. A valid SCT or inclusion proof from a properly behaving log
 provides evidence that the certificate chain was logged. (See Section 9.4
 for a top-level discussion of how an Auditor can detect if a log is
 misbehaving.)

     Currently there is no plan for incremental deployment of CT that will
 result in all authentic certificates being logged. Thus it would be
 inappropriate for a browser to reject a TLS server certificate merely
 because of the absence of an SCT. However, if a later, standards track RFC
 is published that describes a backwards-compatible, incremental deployment
 plan that addresses this problem, then a browser will be able to reject
 certificate chains that are not accompanied by evidence of logging.

     A comprehensive specification of requirements for CT-aware browsers
 will be provided in a document to be published later. If CT is used by
 other TLS clients, then that specification may apply additionally to those
 clients, or another specification may be written to specify behavior for
 those TLS clients.

 Severity:  -            |  Resolution:
 Keywords:               |

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/145#comment:1>
trans <https://tools.ietf.org/trans/>