Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move security-critical client requirement on push to definitive sections #4101

Closed
royfielding opened this issue Sep 16, 2020 · 1 comment · Fixed by #4105
Closed

Move security-critical client requirement on push to definitive sections #4101

royfielding opened this issue Sep 16, 2020 · 1 comment · Fixed by #4105
Labels
-http editorial An issue that does not affect the design of the protocol; does not require consensus.

Comments

@royfielding
Copy link
Contributor

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.

@larseggert larseggert added this to Triage in Late Stage Processing via automation Sep 16, 2020
@larseggert larseggert changed the title move security-critical client requirement on push to definitive sections Move security-critical client requirement on push to definitive sections Sep 16, 2020
@MikeBishop
Copy link
Contributor

MikeBishop commented Sep 17, 2020

The reason it's only a SHOULD 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.

@MikeBishop MikeBishop added the editorial An issue that does not affect the design of the protocol; does not require consensus. label Sep 17, 2020
@project-bot project-bot bot moved this from Triage to Editorial Issues in Late Stage Processing Sep 17, 2020
Late Stage Processing automation moved this from Editorial Issues to Issue Handled Sep 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-http editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing
  
Issue Handled
Development

Successfully merging a pull request may close this issue.

3 participants