Re: New Version Notification for draft-thomson-http-replay-00.txt

Hi,

On Wed, Jul 19, 2017 at 02:20:14PM +0000, Subodh Iyengar wrote:
> Martin, a few others and I discussed this draft offline just after the HTTP WG meeting and I believe there is an extension of the dkg style attack possible on the proposal currently.
> 
> I'm making the following assumptions:
>      * There is no special API to handle 0-rtt data by the TLS terminator, i.e. it is treated as a part of the same 1-rtt stream of data

Does such an implementation really exist ? I mean, for openssl, it's clearly
different :

    https://www.openssl.org/docs/manmaster/man3/SSL_read_early_data.html

So you read early data using SSL_read_early_data() and this one returning
even one single byte indicates that you're getting early data. SSL_read()
will not work before the handshake completes.

I understand how having such an implementation could be an issue but then
this is probably something that should be documented in the draft, explaining
that one of the prerequisites to map HTTP on top of 0-RTT TLS, it's critical
that the API clearly distinguishes early data from regular data.

(...)
> Any strategy that does not provide a custom API for servers to tell the
> difference between 0-rtt and non 0-rtt data suffers from this problem.
> However custom APIs are painful to work with.

One more reason for documenting this case clearly so that there is no
confusion about it!

> Fortunately I think there is a simple fix to this though which is setting the
> early data header from the client directly and then the proxy can just
> forward it through. I understand that this cannot be exactly determined by
> the client, but it could be conservative about it.

Interestingly, we started with this initially, and figured that this was
completely covered by the distinction of early data from regular data,
and caused two other issues :
  - for some clients, changing a header field after a request was attempted
    and before operating a retry might be complicated (ie: the retry will
    very likely happen only at the transport layer)

  - whenever a proxy doesn't support early data, and would receive the whole
    request over regular data, it would have to strip this header field from
    the request. This results in having to deal with 3 values for this header
    field to know whether an attempt to use early data was made by the client,
    and whether at least one proxy in the chain received the request as early
    data.

While I agree that APIs are difficult, I tend to think that the purpose of
the draft is to explain the prerequisites to map HTTP on top of 0-RTT and
that instead of complexifying all implementations and making them more
fragile, we should rather indicate in which cases it's forbidden to enable
0-RTT (ie: SSL implementation doesn't provide a clear distinction between
early data and regular data). This could possibly be justified by using
your attack as an example.

Regards,
Willy

Received on Thursday, 20 July 2017 04:25:55 UTC