Eric Rescorla's No Objection on draft-ietf-httpbis-replay-03: (with COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-httpbis-replay-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4635



COMMENTS
S 3.
>          basis.
>   
>      5.  The server can cause a client to retry a request and not use
>          early data by responding with the 425 (Too Early) status code
>          (Section 5.2), in cases where the risk of replay is judged too
>          great.

I think the point you want to bring out here is that this allows you
to bounce individual requests, as opposed to point #2. In fact, you
might want to say "at the TLS layer" in point #2.


S 3.
>          (Section 5.2), in cases where the risk of replay is judged too
>          great.
>   
>      For a given request, the level of tolerance to replay risk is
>      specific to the resource it operates upon (and therefore only known
>      to the origin server).  In general, if processing a request does not

This is partly true, but note that the client knows whether it would
replay it.


S 3.
>   
>      For a given request, the level of tolerance to replay risk is
>      specific to the resource it operates upon (and therefore only known
>      to the origin server).  In general, if processing a request does not
>      have state-changing side effects, the consequences of replay are not
>      significant.

This seems to contradict the claims in the TLS 1.3 security
considerations about side channels.


S 3.
>      A server can limit the amount of early data with the
>      "max_early_data_size" field of the "early_data" TLS extension.  This
>      can be used to avoid committing an arbitrary amount of memory for
>      deferred requests.  A server SHOULD ensure that when it accepts early
>      data, it can defer processing of requests until after the TLS
>      handshake completes.

I don't understand this last line. You don't have to defer, so why
should you ensure that?


S 4.
>      By their nature, clients have control over whether a given request is
>      sent in early data - thereby giving the client control over risk of
>      replay.  Absent other information, clients MAY send requests with
>      safe HTTP methods (see [RFC7231], Section 4.2.1) in early data when
>      it is available, and SHOULD NOT send unsafe methods (or methods whose
>      safety is not known) in early data.

Is that what browsers plan to do?


S 4.
>      If the server rejects early data at the TLS layer, a client MUST
>      start sending again as though the connection was new.  This could
>      entail using a different negotiated protocol [ALPN] than the one
>      optimistically used for the early data.  Any requests sent in early
>      data MUST be sent again, unless the client decides to abandon those
>      requests.

This MUST in connection with the "unless the client"... seems
confusing. Perhaps "will need to be..."



S 4.
>      were sent in early data, the request will be processed twice.
>   
>      Replays are also possible if there are multiple server instances that
>      will accept early data, or if the same server accepts early data
>      multiple times (though this would be in violation of requirements in
>      Section 8 of [TLS13]).

To be clear, only the second part of this is in violation


S 5.1.
>      An intermediary that forwards a request prior to the completion of
>      the TLS handshake with its client MUST send it with the "Early-Data"
>      header field set to "1" (i.e., it adds it if not present in the
>      request).  An intermediary MUST use the "Early-Data" header field if
>      it might have forwarded the request prior to handshake completion
>      (see Section 6.2 for details).

I don't actually see these details, so perhaps this can be rewritten
more clearly?


S 5.1.
>      A server cannot make a request that contains the Early-Data header
>      field safe for processing by waiting for the handshake to complete.
>      A request that is marked with Early-Data was sent in early data on a
>      previous hop.  Requests that contain the Early-Data field and cannot
>      be safely processed MUST be rejected using the 425 (Too Early) status
>      code.

I think in order for this to be true you need to prohibit clients
sending with Early-Data=1

Received on Thursday, 7 June 2018 07:50:18 UTC