On Mon, Jul 8, 2019 at 8:51 PM Andrew Ayer <[email protected]> wrote:
> On Fri, 5 Jul 2019 11:44:38 +0000 > Rob Stradling <[email protected]> wrote: > > > James Manager commented on this PR [1]: > > > > "The log parameters are not URLs, but URL templates. > > The variables that can appear in the templates need to be defined as > > well. That is, 'first', 'second', 'hash', 'start, and 'end' for > > various templates. > > Otherwise the spec is still forcing URL structure on servers (ie > > variables MUST be querystring fields with these given names)." > > > > How do folks feel about this? > > I'm opposed to using URL templates, as it would increase client > complexity by forcing them to include template interpolation logic. > > This WG has already reached consensus that BCP 190 compliance is > unnecessary for CT, as years of real-world experience with RFC6962 > deployment has showed that no log operator needs the additional > flexibility that BCP 190 aims to provide. I think we should go further > and say that BCP 190 compliance is detrimental to CT, as we've > explored several options to add compliance and they all make CT worse - > by *reducing* flexibility for log operators in a way that actually > causes them problems (well-known), increasing the load on logs > (directories), or by adding complexity to clients (URL templates). I > doubt that the intent of BCP 190 was to make protocols worse. I hope > we can move forward without BCP 190 compliance in CT. > As Andrew mentioned, many of the suggestions seem to concretely make the ecosystem less reliable, by making it easier for Log Operators to exploit the non-cryptographically-verifiable portions of the protocol. A significant motivating factor in the development of Chrome's CT Policy, for example, was to attempt to profile down the extant RFC 6962 flexibility, such as with HTTP error codes and the ability to request payments or authorization for "public" data, in order to ensure that the Logs it used were themselves useful to clients. These, in turn, are themselves arguably security considerations that impact the overall utility of CT. I agree with the discussion about the reasons against .well-known and directories; they highlight real tradeoffs that cause more harm than good. ..well-known should be tightly controlled and restricted; and thus, as a practical matter, makes it difficult to impossible to host CT Logs on a number of domains or server infrastructures. Similarly, as noted, directories pass on costs not only to clients, but to the monitoring ecosystem and to those that wish to ensure Logs adhere to a stated set of operational policies and practices. As it relates to URL templates, I'm less opposed, if only because I expect that a natural consequence of this would be to use policy to profile the URL templates into a predictable form in order to provide the necessary security and reliability. As a consequence, I don't anticipate clients ever needing to implement these, except those clients which might interact with CT Logs that are limited in scope or application, and not widely used. Functionally, this means that the flexibility intended by the use of URL templates is unlikely to be realized in practice in running code. As a consequence, it's a joint of flexibility that will quickly rust shut, because keeping it well-oiled is counterintuitively hostile to the ecosystem. Hopefully that provides a compelling argument against adopting some of said flexibility. However, if there is consensus to do so, despite the various arguments against, I would prefer the URL templates so that they can be most easily profiled away with limited impact to clients and with the least 'industry' profiling of the applicable standard.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
