You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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
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
added
the
editorial
An issue that does not affect the design of the protocol; does not require consensus.
label
Sep 17, 2020
In the HTTP/3 draft 30, section 4.4 on Server Push says
and then adds in 10.4 (https://tools.ietf.org/html/draft-ietf-quic-http-30#section-10.4)
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.
The text was updated successfully, but these errors were encountered: