Request header for Expect-CT

[siyengar]

A request header for Expect-CT would allow servers to know how many clients actually support Expect-CT and might allow us to deprecate this header in the future.

Specifying that you MUST send Expect-CT response unless the header is sent might be nice as well.

[mnot]

This would require including it in Vary on cacheable responses -- something that is going to reduce cache efficiency and also likely to cause operator error.

Is the added complexity/risk worth it?

[estark37]

Also, I expect Expect-CT to be a somewhat niche feature, so we'd probably be adding wasted bytes to the vast majority of requests.

[siyengar]

i imagine HPACK would compress that out, and if it's needed only for a short period of time then when we don't need this header any more, we'd stop sending it from clients. Without this, is there a way we can deprecate this header from ever being sent by a server? User agent hints?

@mnot do we really need to add it on Vary? Clients who get responses with this header and don't support Expect-CT will just ignore it. Clients who get this but have not sent Expect-CT will ignore it. Clients who have deprecated Expect-CT will behave like clients who don't support Expect-CT.

[mnot]

HPACK does not give infinite efficiency; we're already hearing about the dynamic table thrashing for some sites.

If you don't put it in Vary, then an intermediary cache will store the version without the Expect-CT hint and serve it to clients that could have used one.

[estark37]

@siyengar I think that servers could probably just look at User-Agents to determine when the header is no longer applicable for most of the clients contacting them. (I imagine they'll probably end up wanting to keep an eye on the CT policies for the UAs they care about anyway, because the server might not get any value out of Expect-CT even if the UA still supports it. For example, one could imagine a UA that fully requires CT for all certs, but still supports Expect-CT for reporting purposes, in which case a server that is not using reporting would want to not send Expect-CT even though the UA still advertises support for it.)

[siyengar]

@mnot @estark37 the same problem would occur if the server decides not to send Expect-CT based on UA. Either you send the header to everyone, or if you don't send it to everyone, you have to include a Vary: User-Agent instead of a Vary: Expect-CT.

[estark37]

@siyengar I just meant that if a server knows (from looking at UA) that 99.9% of its clients are Browsers X, Y, and Z, then it can stop sending Expect-CT when Browsers X, Y, and Z no longer support Expect-CT.

[reschke]

@estark37 - in that case, it would need to include "User-Agent" in the "Vary" field value....

[mcmanus]

as Emily says, this is a niche server feature. The global number of bytes spent advertising to sites unaware of CT is going to be way more than the number of bytes sent bearing the response header. It can be deprecated just as easily by watching market share counters as anything else. I would close the issue wontfix personally. as a total aside - the hpack pressure is normally on the server table not the client one, right?

…

On Mon, Apr 17, 2017 at 4:59 PM, Julian Reschke ***@***.***> wrote: @estark37 <https://github.com/estark37> - in that case, it would need to include "User-Agent" in the "Vary" field value.... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#317 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP5sxJDxivobMDEHp4bulsjDszXx9Erks5rwynlgaJpZM4MvwJh> .

[siyengar]

@mcmanus that's fair. We can always set Vary: User-Agent if we want to set it for some UAs but not others. It's clunky, but doable.
@estark37 I think I'm fine with this rationale and we can close this out.

[mnot]

Personally - I agree with @estark37 and @mcmanus. There's no need to advertise it in Vary if the server makes a decision about turning it on/off for all requests. That approach is more suitable to this situation IMO.

WRT hpack pressure -- numbers are always interesting, of course, but I'm hearing a lot of people on both sides making proposals with the assumption that hpack will take care of their efficiency problems. That's true, but only to a certain point...

[estark37]

Thanks for the input, everyone.