Ryan,
Thanks for the thoughtful reply and further explanation of your concerns. I agree that what constitutes a pro or con is very much a function of the perceived use context, which is why IETF WGs often (but not always) develop a set of requirements before pursuing the design of solutions. Unfortunately, that was not the case for TRANS. The charter asserts that verifiable logs are the solution for the problem of mis-issuance in the context of HTTP over TLS, but mis-issuance is not defined in the charter or in 6962-bis (although the threat doc does define the term). If we adopt the very general context of any use of HTTP/TLS then it's harder to establish firm requirements based on uniform assumptions, because of the wide range of scenarios that are encompassed. Your discussion of OCSP stapling illustrates the problem, I believe. I support Richard's assumption that browser use of CT is a useful scope for the current doc. Also, as I noted, that context has been the focus of WG discussions since the beginning, as reflected in the two other active WG docs. Steve ________________________________ From: Trans <[email protected]> on behalf of Ryan Sleevi <[email protected]> Sent: Thursday, February 16, 2017 3:41:45 PM To: Steve KENT Cc: Ryan Sleevi; Richard Barnes; [email protected] Subject: Re: [Trans] The importance of understanding auditing On Thu, Feb 16, 2017 at 12:02 PM, Steve KENT <[email protected]<mailto:[email protected]>> wrote: Ryan, I agree that the charter for TRANS refers to TLS client in general, but the WG has long focused primarily (if not exclusively) on browsers as the TLS clients of interest for CT. For example, the gossip document talks extensively in terms of browsers and HTTPS clients, not generic TLS clients. The threat model also talks in terms of browsers as clients of TLS servers, and has done so for a very long time. For browsers we have a model of how trust anchor stores are managed and thus how info about logs could be promulgated (even though these mechanisms are not IETF standards.) For generic TLS clients I don't believe there are similar models, which would suggest gaps in the architecture. Thanks for clarifying Steve. I highlight this concern/divergence because I think it's important to understand whether the disagreements are architectural or political. I think the good comparison here is OCSP, OCSP Stapling, and client policy. For a number of TLS clients (including S2S scenarios or automated tooling), OCSP (with hardfail) is a totally viable scenario. However, we know browsers have raised a variety of concerns with OCSP's deployment in that model, which is where OCSP Stapling serves as a useful bridge for that. However, even with OCSP Stapling, we cannot suggest that it's addressed the revocation threat model unless and until OCSP stapling is mandatory for connections - otherwise, we're back to the same problem. OCSP Stapling being mandatory for connections is more a question of policy than of technology. Similarly, I think it's important to understand where our disagreements exist on technology and whether the perspectives of concerns are things that are true and generic, or if they are specific to certain deployment and trust scenarios. For example, it's quite trivial and easy to imagine a CT deployment scenario in which the client directly communicated with an Auditor/Monitor who could fulfill all the roles necessary for the assurances here - at a certain cost of client privacy (in their communications with the Auditor/Monitor). Richard's discussion highlights things in terms of "pros" and "cons", but evaluating whether something is a pro, con, or neutral implies with it a specific set of requirements and objectives, and I believe those requirements and objectives may differ between potential clients - those both active in TRANS and those absent. That's why I wanted to get a better clarification here about the particular objective set as the WG sees it (vs as Google, Mozilla, or other implementors may see it), and then better articulate the requirements. As an example, imagine a proposal which proposed that for clients, after some period of time, an OCSP response MUST be stapled and the OCSP response MUST include an inclusion proof to an STH within some delta of the OCSP responses' validity period. That is a solution which is effectively coupled to policy - such as whether OCSP responses must be stapled - and to implementation - such as whether OCSP stapled responses should be preferred.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
