Subject: Call for Adoption: Expect-CT

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Dec 2016 15:05:27 +1100

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.

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 8 Dec 2016 13:19:28 +0900

Hello Mark,

> Please comment / express support on list.

I haven't been in Seoul, and haven't read the draft, sorry.

I just have a small procedural question:

Are you expecting everybody who already somehow expressed support to 
repeat that here?

Or are we going to accept the draft based on pre-existing support, and 
this is just a formality to give people who would be opposed a last chance?

Or something in between (and if so, what)?

And similar for the other drafts (where your wording is different, but 
not really clearer).

Regards,   Martin.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Dec 2016 15:22:01 +1100

Hi Martin,

> On 8 Dec. 2016, at 3:19 pm, Martin J. Dürst <[email-masked]> wrote:
> 
> Hello Mark,
> 
> Are you expecting everybody who already somehow expressed support to repeat that here?
> 
> Or are we going to accept the draft based on pre-existing support, and this is just a formality to give people who would be opposed a last chance?

More the latter. It's extremely helpful if people repeat the support they showed "in the room", but experience shows us that people are seldom inclined to do so.

And, to be clear, it's not a count of how many are "for" or "against" -- it's whether there are good technical arguments as to why we should not start work in these areas, or information that shows it might not be useful to do so (e.g., a lack of interested implementors).

> And similar for the other drafts (where your wording is different, but not really clearer).

Likewise.

Cheers,

---

From: Tom Ritter <[email-masked]>
Date: Wed, 7 Dec 2016 23:58:00 -0600

I support. (And have implemented on a server.)

-tom

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 9 Dec 2016 12:13:15 -0800

> On Dec 7, 2016, at 8:05 PM, Mark Nottingham <[email-masked]> wrote:
> 

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

---

From: Emily Stark <[email-masked]>
Date: Fri, 9 Dec 2016 17:57:51 -0800

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

>        (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.

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

> useful for later connections?  As a general design rule, we use links

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

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

---

From: Alessandro Ghedini <[email-masked]>
Date: Sat, 10 Dec 2016 14:15:14 +0000

On Fri, Dec 09, 2016 at 12:13:15PM -0800, Roy T. Fielding wrote:
> certificate itself?

I don't have strong opinions about HTTP header vs TLS extension, but making
this an x509 extensions would severely impact adoption of this mechanism in
the short and medium terms since it would require explicit support from CAs.

Might be worth noting that by using an HTTP header a site behind a third-party
CDN could in theory implement the mechanism itself without support from the
CDN (whether this is a useful thing is unclear though).

Cheers