On Thu, Feb 16, 2017 at 12:02 PM, Steve KENT <[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
