On Fri, Mar 4, 2016 at 11:30 AM, Patrick McManus <mcmanus@ducksong.com>
wrote:
>
> 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.)
Erik
Received on Friday, 4 March 2016 18:50:08 UTC