Re: [secdir] Secdir review of draft-ietf-httpbis-replay

[Magnus Nyström <[e-mail]>]

Yes Martin, I think all of those changes are improvements - thanks for
considering!

/M

On Wed, May 2, 2018 at 6:51 PM, Martin Thomson <[e-mail]>
wrote:

> Yes, thanks Magnus,
>
> I think that Willy answered the primary concerns.  I'm not sure that there
> is anything actionable in those, but if you have a suggestion for
> improvement, that would be appreciated.
>
> > > - Section 2, first sentence: Insert "data" after "application"
>
> This is fixed in the editor's copy (long story there, but the draft you
> reviewed was *slightly* out of date).
>
> > > - In Section 3, step 3, it is stated that: "If the server receives
> multiple
> > > requests in early data, it can determine whether to defer HTTP
> processing
> > > on a per-request basis," however, in Section 4, it is stated that:
> "Note
> > > that a server cannot choose to selectively reject early data at the TLS
> > > layer. TLS only permits a server to accept all early data, or none of
> it" -
> > > I guess this may be consistent (it will accept all data, but can
> > > selectively defer processing), but it is a bit confusing.
>
> > Probably that we need to refine the wording. The point in section 3 was
> > to make it clear that early data may affect multiple requests
> (pipelining,
> > HTTP/2 multiplexing), and point 4 tries to clarify the fact that the TLS
> > layer provides you a data stream, part of which was received as early
> > data, and that the server has no choice but to consume them all or reject
> > them all.
>
> When I went to look at this, I noticed that we don't really explain that
> rejecting 0-RTT is possible.  That's an important option, even if it is
> pretty severely limited.
>
> So I added that:
>     2.  The server can reject early data.  A server cannot selectively
>         reject early data, so this results in all requests sent in early
>         data being discarded.
>
> Full change at: https://github.com/httpwg/http-extensions/pull/602
>
> In doing so, I think that the context needed to interpret step 3 (now step
> 4) is available.
>
> > > - The attack in Section 4 is outlined as follows: "An attacker sends
> early
> > > data to one server instance that accepts and processes the early data,
> but
> > > allows that connection to proceed no further. The attacker then
> forwards
> > > the same messages from the client to another server instance that will
> > > reject early data. The client then retries the request, resulting in
> the
> > > request being processed twice."
> > > This seems a little convoluted - how would the attacker know, before
> the
> > > client has sent the first message, that it is what the client will
> send? Is
> > > the attacker's first message to a server instance intercepted from the
> > > client? If so, suggest making that clear.
>
> > Indeed, that was based on intercepted and replayed traffic. With an
> > individual hat, I agree that the example is a bit conflated. But the
> > point here was mostly to expose the risks that could happen by lazy
> > implementations that would take some shortcuts (like automatically
> > retrying on timeout for a client or a server accepting to process
> > unsafe early-data requests).
>
> Yeah, maybe this alternative is better:
>     Automatic retry creates the potential for a replay attack.  An
>     attacker intercepts a connection that uses early data and copies the
>     early data to another server instance.  The second server instance
>     accepts and processes the early data.  The attacker then allows the
>     original connection to complete.  Even if the early data is detected
>     as a duplicate and rejected, the first server instance might allow
>     the connection to complete.  If the client then retries requests that
>     were sent in early data, the request will be processed twice.
>
> Details at: https://github.com/httpwg/http-extensions/pull/603
>



-- 
-- Magnus