HTTP Working Group Materials

HTTP WG October 2020 Interim - Draft Minutes

20 October 2020, 13:00-14:30 UTC

HTTP Core

(slides)

Julian: presenting…

Tommy: When do we want to target last call

mnot: Roy and I are meeting once a week now. We’re making good progress. I think around IETF 109. Certainly by end of year

Julian: confirm

Tommy: due to the length of these we’ll have a long LC. Please take a look asap

Extensible Prioritization Scheme for HTTP

(slides)

Lucas: presenting… maybe? moving on, we will come back. And we’re back

mt: The first option (same as associated stream) is fine. The request order implies priority. If the push comes after the request that triggers it, that works with H2

Lucas: We have some more explicit guidance on ordering in the text. Good observation

Robin: Not sure I agree. What do you mean by the default? Both urgency and incremental?

Lucas: I don’t know. Are you asking if the push should be incremental?

Robin: We don’t give explicit guidelines of how to handle incremental vs non-incremental in the same bucket, so could get priority inversion when choosing option 1.

Lucas: this comes back to ordering. There are few ways to skin this cat. I think the right answer is to describe the problems that come from exhaustion. The question with relation to push is a good one, we can probably get the wording right.

Robin: If we don’t give explicit guidance, I’d suggest option #2

Kazuho: The problem with option 2 there could be other streams that come before the stream that triggers the push and other streams at the same urgency level, so could lead to other issues. At the same time writing down the problems …

mt: Kazuho is right, Robin also correctly points out problem of choosing incremental vs non-incremental. The right thing to do is to point out the issues. From the chat you have no strict ordering of pushes but we have push IDs that can be inserted between non-push streams and schedulers can use stream ID-based ordering.

Lucas: this is probably best done on GitHub

Tommy: one question on scheduling. Do we want to target a particular time for lc of this doc?

Lucas: H3 is getting towards last call, but there’s not strict dependency, this is non-blocking. For real deployment it will be important to get this in though. Implementations need something practically. Want to finish this asap.

Signing HTTP Messages

Annabelle: presenting

ekr: This is an incredibly general mechanism. Can be self contradictory. I don’t understand how this can be secure

Annabelle: Let me understand.

ekr: The semantics of composition is undefined

Annabelle: they are defined, but I didn’t include it in the slides

ekr: (example) unless we have specifications of HTTP headers, we can’t have deterministic semantics

Annabelle: The utility will depend on the context. What needs to be signed depends on the context. If you depend on the whole header being signed, you should be enforcing that the whole header being signed

ekr: This requires extensive analysis, but in our experience that doesn’t happen. So I don’t think we should create a document with that property

Annabelle: can we goto the next slide to demonstrate how this can be useful

ekr: I don’t dispute that it can be useful

Annabelle: your concern is that people will only sign fragments but not sign pieces that change the semantics

ekr: we see similar issues in signed email, because no one understands what the headers there mean and how they’re signed.

Julian: can you tell us about the reason for splitting it into two headers?

Annabelle: previously unstructured. Most parameters were additional named structures and you had one signature. One of which was the headers param which had a string of identifiers that will be signed. What prompted the split was a few different things. We want to support multiple signatures and have signatures sign over other signatures. We also want to be able to sign the input for a signature. Which creates a compelling reason to split the two out so the signature input cna reference itself. Interested in feedback on if there are other ways to capture those requirements

Cory: Pseudo header elements. Any reason to not use those?

Annabelle: I believe there isn’t a perfect overlap there. it is possible that with this change that that may not be relevant anymore. might be worth looking back at that. would force us not to use the token format because tokens can’t begin with :

Cory: ___

Annabelle: the canonicalization of the __ is to __

Cory: I think binary basic items aren’t don’t have a single canonicalization. There may be some ambiguity that might be worth calling out.

Annabelle: thanks

Justin Richer: (coeditor) to respond to ekr. that’s the entire purpose of signing a piece of a message that can be modified in transit. The enforcement of only trusting the signed portions needs to happen at the application layer. We have experience in how this can be implemented correctly and also how it can go wrong (OpenID 2). Unless we are signing the entire message as an immutable block we are going to have to deal with this problem space.

EKR in comments: My point is that this is a bad idea.

Justin: I don’t agree. It can go wrong, but that doesn’t mean we should ignore it

mnot: we have headers that it is useful to have headers where entities can add to it and sign it. It can also be misused and dangerous where it is misused. Also, I’d love to give feedback on structured headers.

Jeffrey: I agree with ekrs concern. Signed exchanges require that everything is signed. I like that you got counter signtures with this mechanism. I think this draft needs an explicit call out that derived protocols should only use the signed portions

Annebelle: That’s a good call out. There isn’t guidance for profiling specifications. Security considerations is a section that hasn’t gotten attention.

(timing discussion)

Annabelle: presenting

Sam Weiler: I noticed that you see that what key you’re using is out of scope. How does a verifier know what algorithm a message had been signed with. Annebelle: where?

Sam W: e.g, 3.2.1

Annebelle: the selection is out of scope. A profiling spec that builds on this would likely have a key selection registration and selection mechanism. We can add a section to add clarity to that.

Sam W: what happens when someone forges a signature with an algorithm that isn’t widely used. How do we deal with downgrade attacks?

Annabelle: We haven’t specified how a verifier specifies what they will accept. There are cases where it is useful for a verifier to specify ahead of time what they will accept, but that can happend out of band. We need to have those constraints. But not obvious we need that in this draft.

Digest Headers

(slides)

Roberto: presenting…

mnot: we’re running out of time

Roberto: presenting…

Justin: This interlocks with HTTP signatures and this is progressing well. I need to sit down and read the draft. Do you think we can see some alignment between the algorithm spec that digests use and the one that signatures use

Roberto: We removed everything that is below sha256 so I believe there is no issue about legacy. Algorithms are managed externally, but we are glad to work on that to make sure the specifications can integrate.

mnot: getting close to WGLC, so people should have a read

Roberto: thoughts on issue 970

mnot: it is pretty complicated, need to think about it offline

RFC6265bis

mkwst: presenting…

mnot: goal is to reflect reality. I think it is entirely reasonable for the WG to add a few things left. If there are any implementers that say anything please say so now.

ekr: we don’t want to ship things that are in IDs and not in the actual draft. We would be in favor of folding them into the main draft and also shipping the draft.

Julian: I’m on the opposite side, ship the stable spec and define new things in a new revision

Thommy: we have opinions on both sides. Let’s get a written up proposal and have a discussion on list.

mkwst: the cookie incrementalism is written as a set of PRs, so that will be pretty strait forward

22 October 2020, 13:00-14:30 UTC

David Schinazi and Cory Benfield will be your minute takers today.

HTTP/2bis

(slides)

Note from minute taker: let the record show that the 2 in these slides is glorious.

Cory Benfield: this is a good idea, support - kill midders

David Schinazi: Proposed adding removing server push to the list of changes. https://github.com/martinthomson/http2-spec/issues/16

Mike Bishop: Wants to address errata, if the doc is open anyway let’s do some more, no new features.

Julian Reschke: Update references to the core doc, even if it’s only an exercise. Martin to take under advisement.

Yoav Weiss: Opposed to removing priorities from H2. They are implemented and deployed in some places: opposed to removal before new priorities mechanism in place. Martin is open to exploring a wide range of soft-deprecations instead of hard-removal.

Lucas Pardue: Supports this work, willing to contribute. Proposes including HPACK in this effort, e.g. add a new static table.

Ian Swett: on priorities, a middleground approach is good - we should reference the new priorities draft. Also, should we change the ALPN because of existing broken servers (e.g. WebSocket over h2 breaks some servers they abort on SETTINGS). Also we use midders in production so if we remove them we would like a way to negotiate them as an extension.

Alan Frindell: We use push in non-Web contexts so we’d like to keep it. HPACK is probably fine as is.

Mike Bishop: also likes push in non-Web. Changing the HPACK static table would be a breaking change.

Dmitri Tikhonov: +1 to Alan: HTTP/2 is not just for the web, either

Bence Béky: +1 to Cory’s and Alan’s preference to not change HPACK

Cory Benfield: Not worth re-entering queue, but I agree with not removing push. Push is very straight forward to not use: just don’t use it. You can delete the code, set the ENABLE_PUSH setting to zero, and just largely forget it exists, so I’m not motivated to delete it from the spec.

Daniel Stenberg: I’m +1 on keeping push and keeping HPACK as-is

Mark Nottingham: there is clear interest here, let’s work on this as a WG. Perhaps move Martin’s repo to a WG repo. Not hearing anyone saying we shouldn’t do this effort.

Tommy Pauly: agrees

HTTP/2 extensions for HTTP/3

(slides)

Martin Thomson: Proposes reopening RFC 7838 (AltSvc) and 8337 (ORIGIN) as bis documents to revise them and include QUIC. Julian Reschke notes that AltSvc has no errata, ORIGIN has one. Mike doesn’t see the need for a bis on ORIGIN but is open to one for AltSvc.

Mark Nottingham: Nervous about opening these documents up for bis due to concerns about strong feeling around some of the areas the drafts tackle.

Lucas Pardue: the origin errata is mine? It’s not really worth a bis imo

GREASE for HTTP/2

(slides)

Mark Nottingham: Will a new ALPN token be necessary?

Chair sense of the room is to take this to H2bis.

HTTP Grease

No slides.

Question for the group: is this an interesting direction for us to go in?

Jeffrey Yasskin: This document says it’s important not to say which field names are reserved for greasing: why?

Mark Nottingham: This prevents receivers from special-casing reserved fields

Tommy Pauly: Would client implementations participate in experimenting here?

David Schinazi: As a client implementer, Chrome would do participate, at least in the beta channels. Would prefer to GREASE in stable but the web may not be healthy enough to tolerate it.

Julian Reschke: In general this is a good idea. This was somewhat triggered by Yoav’s difficulty deploying client hints: can he update?

Yoav Weiss: We’ve seen a lot of problems in beta/canary/dev. Fixed most of these. Still being rolled out to stable. Generally: what David said.

Mike Bishop: This is a great idea, but this is a new kind of GREASE that is very different from previous GREASE work. Should this doc be experimental?

Mark Nottingham: We want this doc to be authoritative on the topic, experimental weakens that

Martin Thomson: It’s more valuable to have a place to discuss this and reach out to WAFs than to publish an RFC

Julian Reschke: Perhaps we should modify the core specs to be more explicit about saying that headers can have many shapes, even if we don’t call it GREASE

Mark Nottingham: Happy to hear that clients are going to experiment. Doc isn’t the priority, we can pause it for 6 months

Tommy Pauly: We can coordinate in experimental channels

Client Hint Reliability

(slides)

Lucas Pardue: On the topic of ALPS, SETTINGS aren’t the only way to extend HTTP. You could use new frames. I like the idea of improving negotiation of extensions but limiting ourselves to SETTINGS might be too limiting.

David Benjamin: Let’s use frames in general.

Cory Benfield: It seems a bit unfortunate to have ALPS be yet another way to exchange data. Maybe we should fix SETTINGS instead?

David Benjamin: A lot of complexities there, using half-RTT for SETTINGS works in theory but causes many implementations problems in practice. Also we’d need a new ALPN.

Mike Bishop: This reminds me of Alt-Svc. Perhaps we could add this to the HTTPS record?

David Benjamin: DNS is not authenticated in practice today.

Mike Bishop: Instead of extended SETTINGS, just use a new frame each time.

David Benjamin: Unfortunate that there are less frame codepoints than SETTINGS identifiers.

Sam Weiler: We could define this as “only with DNSSEC”.

David Benjamin: Chrome doesn’t support DNSSEC so that’s a no-op for us. Also, DNS has different lifetimes than HTTP/2 connections so they could fall out of sync. It also doesn’t save any round-trips over ALPS, so doesn’t seem worth it.

Tommy Pauly: Next steps?

David Benjamin: We’ll need to figure out what lives in HTTP vs TLS WGs.

Search Method

(slides)

Mark Nottingham: Basically a +0.5, we have customers interested in caching POST

David Schinazi: we have a use-case that wants POST over 0-RTT, so maybe having a way to specify idempotency could be nice

Mark Nottingham: let’s chat more I think you can already do that today

David Schinazi: sorry, I need more caffeine

Martin Thomson: this is interesting, but I haven’t seen interest from many parties in the 5 years where this has existed

Mark Nottingham: I think there’s sufficient interest from what I’ve seen

Roberto Polli: Having a way to make explicit if a request is safe is very important. If we build it they will come.

Nick Harper: Having a way to say that a request is safe is important, I’m not sure that SEARCH is the right answer to that though. Maybe SAFE_POST might be easier.

Julian Reschke: The motivation for picking SEARCH was that there is existing code out there that already knows that it’s safe and idempotent. If we use a new method we’ll have to write more code.

Source on GitHub