Re: HTTP profile for TLS 1.3 0-RTT early data?

2017-05-16 8:36 GMT+09:00 Benjamin Kaduk <bkaduk@akamai.com>:
> [late to the party; pulling snippets from multiple messages]
>
> On 05/13/2017 08:02 PM, Martin Thomson wrote:
>
> Yes, this is going to be subjective.  The great thing about the
> strategy that we have here is that nothing is vulnerable to replay
> unless both client and server agree to that risk.
>
>
> I think in order to strictly get the property that the server has agreed to
> that risk we need the new response code "try again 1-RTT", to accommodate
> servers that cannot buffer the entire 0-RTT request or other edge cases.
> But I don't think that is controversial to have.
>
> It's much trickier for intermediaries, who make this decision without
> a great deal of information, but the calculus is still fundamentally
> the same.
>
>
> I don't think we should let a lack of clarity on what the proxy situation
> will look like keep us from writing up what to do for direct client/server
> interactions -- yes, proxies would be restricted to 1-RTT, but that's the
> state of affairs with TLS 1.2 anyway.
>
>
>
> On 05/12/2017 03:21 AM, Stefan Eissing wrote:
>
> What a client wants to send early, might not be what the server is willing
> to process right away. Servers can always chose to not enable early data at
> all, or, in case of doubt about the data, wait for the handshake to
> complete.
>
> At least in h2 it seems to be clear how to do that, is there a way for
> http/1.1 to do the same? Is there maybe a generic TLS1.3 way to do that?
>
>
> There cannot be a generic TLS 1.3 way to do so; it would be a layering
> violation.  TLS just moves the bytes; the interpretation ("willing to
> process right away") must be done by the application layer.  The application
> is of course free to implement the "buffer everything until handshake
> completion" strategy, but I am not sure we want to mandate that level of
> buffering.

I believe that there could be a generic way, if there is a provision
stating that a client is always required to send Finished. That is the
intention behind the PR:
https://github.com/tlswg/tls13-spec/pull/1017.

Of course, having such provision does require all servers to adopt the strategy.

> If we can define a way for TLS receivers to wait for the handshake, then
> there is no need to expect failure from early data, except servers not
> following this strategy or being reconfigured between sessions.
>
>
> I don't think there's a reliable way to do that, and we'll have to provision
> a way for clients to handle early data failures.
>
>
>
>
> On 05/12/2017 06:36 AM, Kazuho Oku wrote:
>
> 2017-05-12 17:21 GMT+09:00 Poul-Henning Kamp <phk@phk.freebsd.dk>:
>
> --------
> In message
> <CANatvzw9zeVfQMBCXGhakFomL2MaTqFNF65jKWHCDXQQ8rxcTA@mail.gmail.com>
> , Kazuho Oku writes:
>
> The kind of the deployment I was considering was one that deploys a
> TLS terminator that just decrypts the data and sends to backend (i.e.
> TLS to TCP, not an HTTP reverse proxy). My idea was that you could add
> a new field to the Proxy Protocol that indicates the amount of 0-RTT
> data that follows the header of the PROXY Protocol.
>
> Can you even know that at the time you send the PROXY protocol header ?
>
> Actually, you do not even need to know or transmit the exact amount of
> the 0-RTT data when you transmit the PROXY protocol header. What you
> need to transmit is the amount of replayable data.
>
>
> I don't think that information will always be available, as more 0-RTT data
> may still be arriving.
>
> I believe that there could be several ways, but something like below
> should work.
>
> * postpone sending the PROXY Protocol header until receiving the first
> flight of 0-RTT data
> * include the size of the 0-RTT data being received as an attribute in
> the PROXY Protocol header that is sent to the backend
>
>
> There can be multiple flights of 0-RTT data; you don't know it's ended until
> the EndOfEarlyData, which can be quite late.
>
> * postpone forwarding the rest of 0-RTT data to the server until the
> handshake succeeds
>
>
> Does this not require committing to buffer everything (else)?  It's far from
> clear that all devices will be able to do so.
>
> The assumption behind the approach is that the 0-RTT data from the
> client (e.g. HTTP request) will likely fit in one packet, possibly in
> the same packet that carries ClientHello (or in a few number of
> packets that will arrive while the server does DH operation). The
> approach also uses the fact that a successful handshake can be used to
> rule out the possibility of the 0-RTT data being replayed by an
> attacker.
>
>
>
> I cannot see how that would be a widely valid assumption, let alone
> universally valid.
>
> In the general case, I would expect it to be possible to transmit multiple
> complete (h2) requests in 0-RTT data.  Is your proposal to only let the
> first one through and buffer the rest?

Yes. That is what I am suggesting.

I agree that it is not optimal. And it's not something I would be
interested in implementing it.

OTOH, I still anticipate that such method would work well for HTTP,
since I believe that the most common case in which HTTP over 0-RTT
will be used is when a user returns back to a web site after some
time. In such case, only the request for the web page will be sent in
the first flight, and fetching of the resources that are required to
render the web page will start after the response to the first request
starts arriving at the client.

>
>
>
> On 05/11/2017 12:15 PM, Ilari Liusvaara wrote:
>
> Reading the cryptographer's concerns regarding 0-RTT, the main ones
> seem to be:
>
> - Possible lack of strong anti-replay. Possibly leading to >10^6 (!!!)
>   replays.
>   * This is enough to exploit pretty subtle side-channel attacks. And
>     these attacks are at least extremely difficult to defend against.
>   * This causes severe problems for high-performance rate-limiting
>     systems.
>
>
> I mostly expect "all" servers to rate limit 0-RTT acceptances to O(10^4.5)
> per second per SNI name (or similar), i.e., a level that is not expected to
> trigger during normal operation but would slow down a side channel attack.
> Perhaps we should include guidance on this.
>
>
>
>
> On 05/11/2017 10:30 AM, Kazuho Oku wrote:
>
> What I am arguing against is creating a specification that suggests an
> user agent (not an intermediary) to resend HTTP request on a 0-RTT
> enabled TLS connection. 0-RTT is an optimization for connections with
> big latency. Such connections typically cost certain amount of money.
>
>
> "Says who?"  There are many potential use cases for 0-RTT, not all written
> down.
>
> My understanding is that browsers are latching onto research showing that
> even 20 milliseconds of extra delay can affect user response statistics, and
> trying to go as fast as possible.  That applies even on broadband, not just
> on satellite.
>
> Asking the user agent to resend a HTTP request that has been sent over
> a 0-RTT connection not only eliminates the merits provided by 0-RTT
> but also doubles the consumed bandwidth. That does not sound right to
> me. I think the right advise we should provide for such case is: turn
> off 0-RTT.
>
>
> I don't think we should recommend the user agent to resend HTTP requests
> from rejected 0-RTT, but I think we will encounter some situations where it
> is unavoidable.  We can give guidance on how to best avoid it, of course.

Agreed.

>
>
>
>
> On 05/11/2017 06:31 AM, Kazuho Oku wrote:
>
> So, while I agree that it is beneficial to have an agreement on how
> the interaction scheme between the origin server and the application
> running behind (possibly as an informational RFC), I do not see a
> strong reason that we need to introduce some kind of profile due the
> introduction of 0-RTT data in TLS 1.3.
>
>
> Just to clarify: it is mandatory that we have a profile document that
> specifies the interaction between TLS 0-RTT data and HTTP; the TLS 1.3
> specification says that "[p]rotocols MUST NOT use 0-RTT data without a
> profile that defines its use".  That profile document may or may not end up
> being very simple, but it must exist.
>
>
>
> On 05/10/2017 07:23 PM, Mark Nottingham wrote:
>
> 3) Being very explicit on how to handle early data that is rejected and
> forced to be resent following connection establishment (ie, when the server
> forces a client into 1-RTT mode by rejecting the early data).  A worst case
> would be if a server actually handled the early data anyways but the client
> thought the server had rejected it.  In HTTP/1.1 this could result in them
> being off-by-one in requests/responses (and could lead to some HTTP Request
> Smuggling style bugs and vulnerabilities.)
>
> I'd hope that TLS/QUIC are explicit here, and that we wouldn't need to be;
> that's the beauty of layered protocols :)
>
>
> Well, TLS/QUIC are supposed to be explicit about whether early data is
> rejected at the TLS layer, and we can probably rely on that.  But, (1) that
> just means that the data is passed on to the application/HTTP stack, which
> has its own crack to reject (subsets of) the early data.  And, of course,
> (2) there can always be implementation bugs.  So we'll want to be careful
> about the semantics of what rejection at the different layers mean and how
> it is handled.
>
> -Ben



-- 
Kazuho Oku

Received on Tuesday, 16 May 2017 02:59:23 UTC