ietf
[Top] [All Lists]

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

2017-07-06 23:40:31
Hi Melinda,

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

2017-07-05 4:37 GMT+09:00 Melinda Shore 
<melinda(_dot_)shore(_at_)gmail(_dot_)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