Subject: [quicwg/base-drafts] move security-critical client requirement on push to definitive sections (#4101)

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 15 Sep 2020 17:30:18 -0700

In the HTTP/3 draft 30, section 4.4 on Server Push says

```
   The server MUST include a value in the ":authority" pseudo-header
   field for which the server is authoritative; see Section 3.4.

   Clients SHOULD send a CANCEL_PUSH frame upon receipt of a
   PUSH_PROMISE frame carrying a request that is not cacheable, is not
   known to be safe, that indicates the presence of a request body, or
   for which it does not consider the server authoritative.
```

and then adds in 10.4 (https://tools.ietf.org/html/draft-ietf-quic-http-30#section-10.4)

```
   Pushed responses for which an origin server is not authoritative (see
   Section 3.4) MUST NOT be used or cached.
```

I don't think normative requirements belong in security considerations except in reference to that requirement elsewhere. Also, requirements in general should clearly state who is responsible for implementing them, whereas the latter requirement implies a client (maybe). And sending CANCEL_PUSH is kind of like the MUST NOT, but not really the same thing; it seems a bit weak in response given that the server just tried to poison the client.

I think the server MUST is an interop requirement because the client MUST NOT is a critical security requirement. I think both should be described in Server Push and merely noted in the Security Considerations, since they are really important. Way more important than the spec reads now.

My guess is that this is editorial, but is the kind of thing that should be fixed before IESG last call.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4101

---

From: Mike Bishop <[email-masked]>
Date: Thu, 17 Sep 2020 11:51:13 -0700

The reason it's only a cancel push is that the server can't know with certainty for which origins the client considers it authoritative.  The server only knows for which origins *it* believes that it's authoritative.  So having received a push the client considers out-of-bounds, the client can't know for sure whether it's a poisoning attempt or simply a difference in view.

Yes, I think this is editorial, since the core request is to relocate existing text without changing the normative requirements.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4101#issuecomment-694430555

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Sep 2020 06:47:08 -0700

Closed #4101 via #4105.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4101#event-3782697167