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

[Kazuho Oku <[e-mail]>]

Hi Melinda,

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

2017-07-05 4:37 GMT+09:00 Melinda Shore <[e-mail]>:
> 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