Opened 6 years ago

Closed 6 years ago

#145 closed defect (fixed)

Section 9.2 (TLS clients) needs more guidance for browsers

Reported by: kseo@… Owned by: eranm@…
Priority: major Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:
Cc:

Description

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.)

Change History (7)

comment:1 Changed 6 years ago by david@…

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.

comment:2 Changed 6 years ago by eranm@…

My understanding of the original problem raised in the ticket is that the section on TLS clients is vague/confusing because it prescribes some actions but not the results of these actions, is that right?
For example that TLS clients MUST reject an SCT whose timestamp is in the future, but not what it implies for a client to have rejected this SCT. Is this understanding accurate?

If so, we can remedy these particular points. However,my understanding is that prescribing client behaviour is outside the scope of 6962-bis.

Regarding the focus on browsers, I disagree: A significant portion of traffic nowadays is from native mobile applications which rely on SSL+PKI for securing their connections, but are not browsers. Such an application can decide to hard-fail a connection if no valid SCTs are present, for example, because that particular application communicates with a small set of servers, all of which are expected to serve SCTs.

For this reason I think that the proposed text in comment 1 about browsers and incremental deployment is not applicable.

I have proposed re-wording of the example provided, of SCTs with timestamp in the future, here:
https://github.com/eranmes/certificate-transparency-rfcs/commit/c643193aeea93afe57baf7a63589fa5ec4cf5d6e

Does that address at least that case?

comment:3 Changed 6 years ago by eranm@…

Steve Kent replied on the list, attempting to summarize his response:

  • It should be possible to do a black-box analysis of a TLS client to determine if it's CT compliant. So prescribing requirements that can't be verified is a bad idea.
  • He does not agree that with the suggestion that the TLS client discussion should be considered generic (i.e. not specific to browsers).
  • He claims that "now there's a new, different reason for sort-of specifying client behavior without really specifying it?". (I don't fully understand why this argument is made).

Based on his reply I will push the change mentioned in comment #2 for review, which will address the first issue.

As for the other issues they are broader and I will leave them for discussion on the mailing list.
My opinion is that any browser-specific guidance provided in this RFC should be non-normative, since there are real-world scenarios where 6962-bis could be applied to non-browser TLS clients. But I really don't see the point of suggesting any behaivour to browsers - they're perfectly capable of figuring out themselves what to do once CT compliance/non-compliance has been established.

comment:5 Changed 6 years ago by eranm@…

  • Owner changed from draft-ietf-trans-rfc6962-bis@… to eranm@…

comment:7 Changed 6 years ago by melinda.shore@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.