Re: [TLS] The case for a single stream of data

[Ilari Liusvaara <[e-mail]>]

On Tue, May 09, 2017 at 11:44:14AM -0700, Colm MacCárthaigh wrote:
> On Tue, May 9, 2017 at 11:12 AM, Ilari Liusvaara <[e-mail]>
> wrote:

> 
> Because HTTP specification expressly forbids any and all updates and
> > writes using safe methods. Ignoring that causes very severe security
> > vulernabilities even today (e.g., causes essentially undefendable CSRF
> > attacks).
> >
> 
> These aren't browser requests, they can be SDK and other clients making
> HTTP API requests. That's much more common too, by volume. CSRF isn't an
> issue in cases like that.

Hope your API is actually idempotent, because the HTTP code, which sits
below the SDK code can replay requests on its own...
 
> I think everything I'm writing applies even for a careful REST-compliant
> case too. Even if the client is using PUT or POST or DELETE or whatever,
> the same kind of transactional semantics apply. All it takes is a
> disconnect between the settings in any of the middle transport layers and
> the expectations of the underlying protocol. I just think that disconnect
> is very predictable.

PUT and DELETE are also subject to autoretry. Which means that any
PUT or DELETE in failed 0-RTT can be immediately replayed as 1-RTT by
the HTTP code.

However, POST is not subject to autoretry. Which means that any POST
in failed 0-RTT must be reported to next layer as "error: connection to
server lost before reply was received". Which is the same error if
server somehow sent a TLS close_notify with pending POST (which is
considered autenticated close!).

(In HTTP/2, if the server explicitly refuses the stream POST is on,
that does not count as fatal failure, and the http library can
autoretry).

The next layer can then decide to retry the request upon getting the
connection lost error. However, in such situation, one _always_ needs
to handle possible reordering, _regardless_ of 0-RTT or TLS version!



Unified-stream model has the following to keep in mind:

- The client TLS library APIs must not be subject to races that may
  cause data corruption if server rejects 0-RTT (_including_ selecting
  different application-layer protocol).
- The 0-RTT data may not be suitable for replay, even if application-
  layer protocol matches. And 0-RTT containing HTTP POSTs is the not
  the only case even in HTTP (e.g. what Tokbind has specified so far
  renders such replay unsafe even for GET).



Two recommendations:

- Always require strong 0-RTT anti-replay, even accross servers. The
  attacks raising from failing to do this are just too severe and
  virtually impossible to address in any other way.
- Clients shall treat any 0-RTT data sent as potentially received by
  the server, _even_ if server refuses the 0-RTT.




-Ilari