On Wed, Feb 15, 2017 at 12:50 PM, Richard Barnes <[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
