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. Steve ________________________________ From: Trans <[email protected]> on behalf of Ryan Sleevi <[email protected]> Sent: Wednesday, February 15, 2017 8:19:07 PM To: Richard Barnes Cc: [email protected] Subject: Re: [Trans] The importance of understanding auditing On Wed, Feb 15, 2017 at 12:50 PM, Richard Barnes <[email protected]<mailto:[email protected]>> wrote: At base, in order to meet this group's charter deliverables, what we want to be assured of is that the mechanisms in 6962-bis that are intended to enable public verifiability can actually do so in practice. That is, we need to establish that there is at least one plausible story for how some substantial fraction of the statements logs provide to clients end up getting audited. If I may, it seems like you're stating two (different) goals as equivalent; the subtlety here at least deserves calling out. For recap, the charter is https://datatracker.ietf.org/wg/trans/charter/ , with the work item being "Publish an update to RFC 6962 as a standards-track mechanism to apply verifiable logs to HTTP over TLS." The subtlety here I'm calling out is that you're implicitly treating "clients" to mean "common Web browsers". While I certainly agree that's an important use case to consider (and certainly one we at Google have been considering), your interpretation is much more narrower than what's chartered, and your concerns much more specific to individual products (on particular platforms), rather than to either the general case of "Web browsers" or even "TLS clients". The danger in this approach is that it bleeds dangerously close to specifying implementation policy, when the current draft provides infrastructure to support a variety of policies for a variety of consumers and clients. Notable here is that you can have CT clients that may decide to 'hard-fail' - whether browser or otherwise - and so some of the 'pragmatic' cons you highlight aren't exactly relevant to the chartered objective, or refer to implementation details and product decisions rather than generalized problems. I think perhaps if we can agree on the scope and its relevance to the charter - which you're highlighting as the key concern - we can better work through these issues. For example, if you imagine a command-line TLS client (such as wget or curl), neither Option M nor Option G, as you've defined them, may be suitable. Does that mean it's necessarily to fundamentally alter how 6962-bis works? Maybe, maybe not. Does that mean it's necessary for such a "guidance document" to consider wget and curl's needs as equivalent to the presumed consumers of Option M or Option G? Maybe, maybe not.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
