http-extensions
http-extensions copied to clipboard
httpwg
Signatures & server push
The draft focuses on the conventional interactions for client-sent requests and server-sent responses. But there seems to be no consideration about server push. I'm not strongly advocating that signatures should spend a lot of effort considering server push, but it does seem like a small gap.
Since PUSH_PROMISE frames contain a field section that represents a request message, all the text that applies to signing requests should jut apply in the same way. So maybe that is all that should be said.
For an example use case: see our signing of PUSH_PROMISE using cavage signatures in https://www.ietf.org/archive/id/draft-pardue-quic-http-mcast-09.html#appendix-B.2.5
Right now, the only targets are defined as request and response https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-10.html#section-2.2-6 -- how does the PUSH_PROMISE change that target? Would you like to propose text?
I don't think it does change the text substantially. Perhaps a single sentence that "In the case of server push, both request and response are generated by the server."
My instinct is just it would be sufficient to identify that pushed requests with a signature are a thing that can happen.
The more I think it, the more I wonder what is expected to be done by the client if it receives a signed push. Should the client validate it immediately? If validation fails, what should it do? There's an associated response that is going to come after the push, is it OK to process the response? Maybe the client should cancel the response before it arrives.
We might not need to answer that in this document. But if not it could help to tell applications that they need to de ide what to do themselves.
From what I can tell, this would mostly be relevant to the section on how to process the message components, and determine the context. I don't think it changes anything on the part of the client's processing requirements.
I am not enough of an expert in QUIC to know how this would work, looking to the WG for input on how to handle this within the document (if at all).
Nominally Server Push works similarly in H2 and H3. If we write anything, it can be written in a way that talks about messages and can apply to both.
From @LPardue at HTTPbis meeting:
in server push, the server synthesizes a request and sends it to the client. If it signs that request, and the client verification of that signature fails, would this spec specify any behaviour to take? For instance, should the client reject the subsequent pushed response that relates to the failed request
My .02 is that a specific usage scenario would need to specify what to do; we shouldn't (and perhaps even can't) create generic requirements here.
