W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2017

Re: Secdir last call review of draft-ietf-httpbis-early-hints-03

From: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 7 Jul 2017 13:40:06 +0900
Message-ID: <CANatvzx8GsvoYMscHciKNrOwRzcz1v7=jTCUUp4Z5E=jO9Wd6g@mail.gmail.com>
To: Melinda Shore <melinda.shore@gmail.com>
Cc: secdir@ietf.org, draft-ietf-httpbis-early-hints.all@ietf.org, IETF Discussion Mailing List <ietf@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Melinda,

Thank you very much for the review. My responses below.

2017-07-05 4:37 GMT+09:00 Melinda Shore <melinda.shore@gmail.com>:
> Reviewer: Melinda Shore
> Review result: Has Issues
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> Summary:   Has minor issues.
> This draft defines a status code for sending an informational
> response that contains header fields that are likely to be included in the
> final response.  A server can send the informational response containing
> some of the header fields to help the client start making preparations
> for processing the final response, and then run time-consuming operations
> to generate the final response.  The informational response can also be used by an
> origin server to trigger HTTP/2 server push at a caching intermediary.
> Passed nit checker without complaints other than publication date.  Sections
> 5 and 6 should be appendices.

The issue has been fixed in the github repo.

> One minor issue: in the security considerations section, "Therefore,
> a server might refrain from sending Early Hints over HTTP/1.1 unless when
> the client is known to handle informational responses correctly" is a bit squishy
> (and contains a superfluous "when").  I'm not sure this merits a text change and
> I'm rather certain that it doesn't merit normative 2119 language but it did stand
> out as an overly soft recommendation.

The superfluous "when" has been removed from the github repo.

Regarding the wording, I think it would be better to keep the tone
as-is, rather than suggesting implementers not to send an Early Hints
response over HTTP/1.1 depending on the client.

Users behind a proxy that cannot handle informational response
correctly is exposed to response splitting attack regardless of if
Early Hints is used (in HTTP/1.1, a server is allowed to send any
informational response at it's own discretion).

So while it is beneficial to warn the risks, I think that there is no
merit in restricting the use of Early Hints.

Kazuho Oku
Received on Friday, 7 July 2017 04:40:39 UTC

This archive was generated by hypermail 2.3.1 : Friday, 7 July 2017 04:40:47 UTC