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

From: Melinda Shore <[email-masked]>
Date: Tue, 04 Jul 2017 12:37:17 -0700

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.

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.

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 7 Jul 2017 13:40:06 +0900

Hi Melinda,

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

> 5 and 6 should be appendices.

The issue has been fixed in the github repo.

> 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

---

From: Melinda Shore <[email-masked]>
Date: Thu, 6 Jul 2017 21:53:53 -0800

> response over HTTP/1.1 depending on the client.

Yeah, you don't want to discourage implementation.  I think
the goal is to find some balance between not putting off
implementers on the one hand, and having to deal with an
embarrassing incident on the other.  I'd be more comfortable
with language that's a bit stronger but it's not a huge
issue, certainly not one that's an impediment to moving the
document forward (particularly given that it's intended for
publication as an experimental standard).  In general I
thought the draft was clearly written and straightforward,
and ready for publication modulo this one minor issue.

Melinda

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 7 Jul 2017 11:23:16 +0200

On Fri, Jul 07, 2017 at 05:54:41AM +0000, Melinda Shore wrote:
> publication as an experimental standard).

I'm just thinking about the fact that we're not even sure that any 
HTTP/1.1 client doesn't support these informational responses,
because such clients can already make use of Expect: 100-continue
(so they know about 100), and if I remember well when designing the
101 upgrade for WebSocket, which was reused for HTTP/2, some of
the difficulties we faced was that some clients/intermediaries
were consuming 101 as 1xx and waiting for a final response after
it.

Maybe the stronger wording should be oriented differently, such as
"Servers MUST not send 103 to HTTP/1.0 clients nor to any client
known not to support 1xx informational responses" ? This way it
leaves the possibility opened (ie rely on version and/or user-agent
or anything else once an exception is known).

Just my two cents,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 7 Jul 2017 19:33:17 +1000

> or anything else once an exception is known).

RFC7231 already says "Since HTTP/1.0 did not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client."

--
Mark Nottingham   https://www.mnot.net/

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 7 Jul 2017 20:29:36 +0900

> or anything else once an exception is known).

Considering that this is merely an advice on how to deal with broken
clients, I think that we should not use the verbs defined in RFC 2119
or state a strong prohibition.

I also believe that a whitelist-based approach will be a better choice
than a blacklist-based one, since 103 is an optimization that is
beneficial when sent to a client that is known to make use of it. For
most websites, whitelisting the major browsers that support it (once
they do) or the CDN they use will be enough to get the most out of the
status code.

-- 
Kazuho Oku

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 7 Jul 2017 13:44:19 +0200

I am not a big fan of "MUST not use protocol features if it is known not to work" advise.

> Am 07.07.2017 um 13:29 schrieb Kazuho Oku <[email-masked]>:
>

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 7 Jul 2017 13:56:01 +0200

> they do) or the CDN they use will be enough to get the most out of the

OK. That was just a proposal :-)

Willy