Re: [Trans] Directory instead of .well-known for URL structure

[Ryan Sleevi <[e-mail]>]

On Mon, Jul 8, 2019 at 8:51 PM Andrew Ayer <[e-mail]> wrote:

> On Fri, 5 Jul 2019 11:44:38 +0000
> Rob Stradling <[e-mail]> 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.