Re: Call for Adoption: Expect-CT

On Fri, Dec 9, 2016 at 12:13 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> > On Dec 7, 2016, at 8:05 PM, Mark Nottingham <mnot@mnot.net> wrote:
> >
> > Again, there seemed to be strong support in Seoul, and now on the list,
> for adopting this draft:
> >
> > <https://tools.ietf.org/html/draft-stark-expect-ct>
> >
> > Please comment / express support on list.
>
> I don't have a problem with someone at IETF working on a solution to the
> problem, but I have serious issues with this draft as it currently stands:
>
>  1) It effectively adds a binary TLS control option in the form of a
>     verbose HTTP response header field to be sent in ALL https responses.
>     That doesn't make any sense, on so many levels.
>
>     a) it's a layer violation (wrong code parses it);
>     b) it's incredibly inefficient to send the information every time
>        when it only needs to be received once;
>

This is a recurring problem common to HSTS, HPKP, Content-Security-Policy,
and probably others, and I'm hopeful that the solutions being discussed at
https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0553.html will
help the situation.


>     c) it's processing is in the critical path of response handling
>        even though the information is only useful for "future connections"
>        (and ignored by all non-implementators);
>

It's also used on the current connection, to report violations. If a server
serves an Expect-CT header with a report-uri on a connection that is not
CT-compliant, then the UA sends a report to notify the server.


>     d) the same control might be desirable for non-HTTP uses of TLS.
>
>  2) The header field is poorly named (see Expect), doesn't limit itself to
>     responses (aside from having no definition for other contexts), and has
>     a field value syntax matching that of Set-Cookie (FFS).
>

These seems like eminently solvable problems.

I'll note that the field value syntax is chosen to align with HSTS and HPKP
so that browsers don't have to implement new parsers to support Expect-CT.


>
> Why is this not a TLS option, preferably signaled by an attribute of the
> certificate itself?  The other information could be supplied at a
> well-known
> location or by reference to a third-party reporting mechanism.
>
> What is the justification for sending this information in HTTP response
> header fields when it is independent of the current response and only
> useful for later connections?  As a general design rule, we use links
> for that.
>

See above; it's not only useful for later connections.


>
> I know HTTP is "comparatively easy" when it comes to adding all sorts
> of fun options, but does this extension justify its own cost?  Why can't
> it be accomplished via the certificate management mechanism, entirely
> outside the scope of this working group?
>

It's a timeboxed mechanism to help browsers and servers transition to a
(hopefully near) future in which browsers require CT for all certificates.
That means a good chunk of its value is in having it widely deployed within
the next year or so. (I elaborated on this a bit at
https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0575.html.)
Getting it widely deployed as a TLS or X509 extension in that time frame
isn't feasible.


>
> ....Roy
>
>
>