Re: Call for Adoption: Expect-CT

> 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;
    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);
    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).

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.

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?

....Roy

Received on Friday, 9 December 2016 20:13:48 UTC