W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: Stephen Farrell's No Objection on draft-ietf-httpbis-alt-svc-12: (with COMMENT)

From: Erik Nygren <erik@nygren.org>
Date: Fri, 4 Mar 2016 13:49:39 -0500
Message-ID: <CAKC-DJjYQHJW=NkbhJZ6jKo3GJ4DnLY-Z_=Xe19vZeLG-dT-rQ@mail.gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mark Nottingham <mnot@mnot.net>, The IESG <iesg@ietf.org>, Mike Bishop <michael.bishop@microsoft.com>, HTTP WG <ietf-http-wg@w3.org>
On Fri, Mar 4, 2016 at 11:30 AM, Patrick McManus <mcmanus@ducksong.com>

> I think the right place to document this would be alongside the
> documentation of the replay cache mitigation.. as far as I understand that,
> the issue is that the cache is a physical resource and any kind of load
> balancing (l4, DNS A records, or alt-svc) is going to limit its efficacy.

A replay cache is not sanely possible to protect against TLS 1.3 0RTT for
any distributed deployment (multi-site with or without Alt-Svc).

It will likely make sense for the HTTP WG to pull together a draft on how
HTTP can be safely used in scenarios where replays can't be prevented.
(TLS 1.3 0RTT, QUIC 0RTT, and perhaps TCP FastOpen for HTTP-over-TCP.)
Much of the responsibility ends up landing on the client to not send
non-idempotent Early Data, but there are also questions and challenges
around how proxies and other middle-boxes should handle data received via
Early Data, how they need to indicate it to the next-hop, and whether it's
ever safe for them to send something not received over Early Data to a next
hop over Early Data.
(With the assumption that Early Data is always replayable, which is why TLS
mandates it has a separate interface to use.)

Received on Friday, 4 March 2016 18:50:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC