hi!
", "time": "2023-07-26T16:32:28Z"}, {"author": "Julian Reschke", "text": "ha, we can resume!
", "time": "2023-07-26T16:33:59Z"}, {"author": "Marius Kleidl", "text": "Here is the mentioned repository of resumable upload implementations: https://github.com/tus/draft-example
", "time": "2023-07-26T16:35:35Z"}, {"author": "Julian Reschke", "text": ":+1:\ud83c\udffb
", "time": "2023-07-26T16:37:57Z"}, {"author": "Julian Reschke", "text": "mic: in any case, we'll need a media type for use with the PATCH method
", "time": "2023-07-26T16:42:00Z"}, {"author": "Marius Kleidl", "text": "Good point, thank you Julian
", "time": "2023-07-26T16:42:48Z"}, {"author": "Shivan Sahib", "text": "we depend on drafts in other WGs all the time
", "time": "2023-07-26T16:43:17Z"}, {"author": "David Schinazi", "text": "Do we have a jabber scribe for this session? (Julian had a \"mic:\" above)
", "time": "2023-07-26T16:43:59Z"}, {"author": "Martin Thomson", "text": "with all respect to Austin, I never take the assessment of a draft author about the status of their own draft
", "time": "2023-07-26T16:44:01Z"}, {"author": "Evert Pot", "text": "I may be wrong but I think the use of Content-Range in requests may be contentious
", "time": "2023-07-26T16:44:14Z"}, {"author": "Julian Reschke", "text": "sounds cool as it would enable better progress reporting
", "time": "2023-07-26T16:50:29Z"}, {"author": "Mike Bishop", "text": "I think the challenges with interim responses mostly boil down to not being able to use them. Clients with that problem won't benefit, but adding status shouldn't hurt anything and might help other clients.
", "time": "2023-07-26T16:53:12Z"}, {"author": "Erik Nygren", "text": "I'd also be wary of including 1xx from a bugs/risks perspective, such as introducing HTTP Request Smuggling vulnerabilities. Are there existing and widely deployed similar 1xx uses?
", "time": "2023-07-26T16:54:07Z"}, {"author": "David Schinazi", "text": "MASQUE all the things!
", "time": "2023-07-26T16:54:16Z"}, {"author": "Mike Bishop", "text": "Chairs, note the timer is still set for the previous speaker.
", "time": "2023-07-26T16:54:17Z"}, {"author": "Martin Thomson", "text": "I don't think that you can stop 1xx for this @Erik Nygren
", "time": "2023-07-26T16:54:36Z"}, {"author": "Austin Wright", "text": "That is a good point Martin and I ought to have emphasized the same point\u2014I should rather say I'm expressing my hope that byterange patch I-D is one of the _relatively_ simpler proposals in front of the WG at the moment
", "time": "2023-07-26T16:54:39Z"}, {"author": "Watson Ladd", "text": "I realize now I'm a bit confused about overlapping upload parts and the partial responses only show that I am confused.
", "time": "2023-07-26T16:55:47Z"}, {"author": "Marius Kleidl", "text": "@Watson Ladd: To maybe help your confusion: In the draft we do not allow overlapping parts for easier handling
", "time": "2023-07-26T16:57:29Z"}, {"author": "Mike Bishop", "text": "If you're in HTTP/1.1 and the client started sending assuming the upgrade, the connection state is garbage. The only sane thing the client can do is close the connection.
", "time": "2023-07-26T17:01:23Z"}, {"author": "Eric Orth", "text": "Does anybody still care enough about HTTP/1.1 that it's not reasonable enough to just say you need to use HTTP2 if you want to send optimistic data?
", "time": "2023-07-26T17:02:29Z"}, {"author": "Alex Chernyakhovsky", "text": "I was about to make the same suggestion
", "time": "2023-07-26T17:02:40Z"}, {"author": "Alan Frindell", "text": "are we ready to deprecate HTTP/1.1
", "time": "2023-07-26T17:04:22Z"}, {"author": "Tommy Pauly", "text": "I do not care about sending optimistic data in H1
", "time": "2023-07-26T17:05:14Z"}, {"author": "Tommy Pauly", "text": "I do not care about this kind of proxying in h1 =)
", "time": "2023-07-26T17:05:26Z"}, {"author": "Watson Ladd", "text": "But what's the benefit of intermediate ack? Just make it easier to free up storage earlier, and then smaller recovery on failure while having enough to ship big chunks for flow? I think I need to deconfuse my self
", "time": "2023-07-26T17:05:30Z"}, {"author": "Anthony Somerset", "text": "given that we have HTTP/3 now surely its time to begin the journey of deprecating HTTP/1.1? or at least formally freeze any extension/feature work
\nmuch the same as TLS WG is planning to do with TLS 1.2
", "time": "2023-07-26T17:07:00Z"}, {"author": "Julian Reschke", "text": "disagree on \"freeze\", but agree on \"does not have to work with 1.1\"
", "time": "2023-07-26T17:09:07Z"}, {"author": "Eric Orth", "text": "I doubt implementors are ready to completely deprecate 1.1 now, but I'd certainly be in support of saying 1.1 no longer gets the new advanced/optimized stuff like optimistic data in upgraded proxy connections. Anybody who wants stuff like that is probably already using 2/3.
", "time": "2023-07-26T17:09:11Z"}, {"author": "Evert Pot", "text": "Deprecating HTTP/1.1 would be a sad day for the web
", "time": "2023-07-26T17:10:05Z"}, {"author": "Alan Frindell", "text": "The nature of HTTP/1.1 makes it really ripe for these kinds of problems. It's a security footgun. There's no fix. We should be opinionated about this.
", "time": "2023-07-26T17:10:14Z"}, {"author": "Martin Thomson", "text": "Walking back a bunch of the \"performance\" allowances for HTTP/1.1 and replacing them with \"close the connection\" might be sensible.
", "time": "2023-07-26T17:11:05Z"}, {"author": "Martin Thomson", "text": "I don't think that we can ignore HTTP/1.1 for this in the way that Alex suggests.
", "time": "2023-07-26T17:11:20Z"}, {"author": "Mike Bishop", "text": "Yes -- don't allow optimistic sending in H1. However, that may not close the risk to the server specifically.
", "time": "2023-07-26T17:12:11Z"}, {"author": "Erik Nygren", "text": "We also need to watch out for implementations that do H2->H1 translation internally as there may still be request smuggling issues there if they don't understand this but clients are using H2.
", "time": "2023-07-26T17:12:46Z"}, {"author": "Alex Chernyakhovsky", "text": "@Martin Thomson I meant \"don't allow optimistic sending\" when I said \"don't do performance features\". Sorry if I was unclear at the mic, I was trying to be brief.
", "time": "2023-07-26T17:12:48Z"}, {"author": "Jonathan Hoyland", "text": "If people could check the notes that would be super helpful. I couldn't keep up with the essays / monologues :sweat_smile:
", "time": "2023-07-26T17:13:05Z"}, {"author": "Tommy Pauly", "text": "Yes, we can prevent optimistic sending but allow the rest
", "time": "2023-07-26T17:13:07Z"}, {"author": "Martin Thomson", "text": "@Alex Chernyakhovsky OK, good. That's sensible.
", "time": "2023-07-26T17:13:09Z"}, {"author": "Jonathan Hoyland", "text": "https://notes.ietf.org/notes-ietf-117-httpbis
", "time": "2023-07-26T17:13:17Z"}, {"author": "Julian Reschke", "text": "FWIW: are resumable uploads a \"performance feature\"?
", "time": "2023-07-26T17:13:20Z"}, {"author": "Martin Thomson", "text": "However... The problem with Upgrade exists.
", "time": "2023-07-26T17:13:23Z"}, {"author": "Benjamin Schwartz", "text": "An UPDATE to RFC 9298 to clarify that optimistic sending is forbidden in HTTP/1.1 seems very short and sufficient.
", "time": "2023-07-26T17:13:37Z"}, {"author": "Tommy Pauly", "text": "Yes we still need to react to upgrade correctly. But prohibit body data before we get the response.
", "time": "2023-07-26T17:13:46Z"}, {"author": "Martin Thomson", "text": "@Julian Reschke I think that I should have scoped \"performance features\" to connect and upgrade and related. Not universally.
", "time": "2023-07-26T17:14:01Z"}, {"author": "Martin Thomson", "text": "@Benjamin Schwartz I think that we probably need to deal with Upgrade more generally also.
", "time": "2023-07-26T17:14:26Z"}, {"author": "Martin Thomson", "text": "@Mark Nottingham @Tommy Pauly is the queue closed still?
", "time": "2023-07-26T17:15:04Z"}, {"author": "Martin Thomson", "text": "Thanks
", "time": "2023-07-26T17:15:16Z"}, {"author": "Tommy Pauly", "text": "I'm on beta meet echo and it doesn't let me close or unclose the queue
", "time": "2023-07-26T17:15:37Z"}, {"author": "Benjamin Schwartz", "text": "\"HTTP Upgrade Requires Patience\"
", "time": "2023-07-26T17:15:57Z"}, {"author": "Martin Thomson", "text": "\"HTTP upgrade requires synchronization\" - pronounced hearse
", "time": "2023-07-26T17:16:47Z"}, {"author": "Tommy Pauly", "text": "\"Optimism Not Allowed With HTTP Upgrade\"
", "time": "2023-07-26T17:16:48Z"}, {"author": "Alex Chernyakhovsky", "text": "HyperText Transport Pessimistic protocol
", "time": "2023-07-26T17:17:17Z"}, {"author": "Julian Reschke", "text": "FIELDs
", "time": "2023-07-26T17:19:20Z"}, {"author": "Martin Thomson", "text": "BEES!
", "time": "2023-07-26T17:20:28Z"}, {"author": "Martin Thomson", "text": "", "time": "2023-07-26T17:21:01Z"}, {"author": "Julian Reschke", "text": "yes, it can
", "time": "2023-07-26T17:23:34Z"}, {"author": "Julian Reschke", "text": "https://greenbytes.de/tech/webdav/rfc9110.html#rule.token.separators
", "time": "2023-07-26T17:23:44Z"}, {"author": "Eric Orth", "text": "I personally really don't care how we jam the non-human-readable string into a header.
", "time": "2023-07-26T17:24:47Z"}, {"author": "Julian Reschke", "text": "\"this is just syntax\" (famous last words)
", "time": "2023-07-26T17:25:07Z"}, {"author": "Martin Thomson", "text": "SIGn-and-MAc FTW
", "time": "2023-07-26T17:28:42Z"}, {"author": "Martin Thomson", "text": "We can use raw public keys, I believe
", "time": "2023-07-26T17:29:08Z"}, {"author": "Benjamin Kaduk", "text": "Jonathan is having a conversation with someone who is not getting picked up by the mic
", "time": "2023-07-26T17:30:22Z"}, {"author": "Martin Thomson", "text": "Nick sullivan off-mic suggested something about there being an early-data-specific version of EA
", "time": "2023-07-26T17:30:49Z"}, {"author": "Martin Thomson", "text": "No token binding please
", "time": "2023-07-26T17:31:07Z"}, {"author": "Benjamin Kaduk", "text": "You might also be able to conjure up a thing where you define an exporter to use as the \"server context\" that the EA needs, for this unprompted auth case
", "time": "2023-07-26T17:32:31Z"}, {"author": "Martin Thomson", "text": "One tiny wrinkle:
\n\n", "time": "2023-07-26T17:32:44Z"}, {"author": "Tommy Pauly", "text": "Only the X.509 certificate type defined in [RFC8446] is supported. Alternative certificate formats such as Raw Public Keys as described in [RFC7250] are not supported in this version of the specification and their use in this context has not yet been analyzed.
\n
Yes that is true
", "time": "2023-07-26T17:33:28Z"}, {"author": "Tommy Pauly", "text": "It'd be good to open that up and allow RPK
", "time": "2023-07-26T17:33:40Z"}, {"author": "Martin Thomson", "text": "Seems like we could work with that.
", "time": "2023-07-26T17:33:40Z"}, {"author": "Tommy Pauly", "text": "Indeed
", "time": "2023-07-26T17:33:53Z"}, {"author": "Martin Thomson", "text": "I think that I know how to fix this if we go with EAs. Certificate compression.
", "time": "2023-07-26T17:35:43Z"}, {"author": "Martin Thomson", "text": "Having the client and server agree on the content of the keys is probably a good idea. TLS has solutions for this.
", "time": "2023-07-26T17:36:53Z"}, {"author": "Benjamin Kaduk", "text": "Relying on a database of key id-> key to be always correct and accurate worries me.
\nThat database disallowing key rotation seems pretty problematic
(Also, in the JOSE/COSE/etc. world key IDs are explicitly not unique and can map to multiple different keys.)
", "time": "2023-07-26T17:38:46Z"}, {"author": "Jonathan Hoyland", "text": "Martin Thomson said:
\n\n\nHaving the client and server agree on the content of the keys is probably a good idea. TLS has solutions for this.
\n
So I did try a version where you just sent the hash of the key as the key_id. That fixes a lot of issues, but presupposes you can agree the hash function.
", "time": "2023-07-26T17:41:27Z"}, {"author": "Jonathan Hoyland", "text": "Benjamin Kaduk said:
\n\n\nRelying on a database of key id-> key to be always correct and accurate worries me.
\n
\nThat database disallowing key rotation seems pretty problematic
Yeah, using key_id only required \"database is written in the sky in flaming letters\"
", "time": "2023-07-26T17:42:19Z"}, {"author": "Jonathan Hoyland", "text": "Benjamin Kaduk said:
\n\n\n(Also, in the JOSE/COSE/etc. world key IDs are explicitly not unique and can map to multiple different keys.)
\n
Ok, that's gonna break _all_ my proofs. This is terrifying.
", "time": "2023-07-26T17:42:41Z"}, {"author": "Benjamin Kaduk", "text": "Jonathan Hoyland said:
\n\n\nBenjamin Kaduk said:
\n\n\n(Also, in the JOSE/COSE/etc. world key IDs are explicitly not unique and can map to multiple different keys.)
\nOk, that's gonna break _all_ my proofs. This is terrifying.
\n
I mean, everybody wants their key to use the key ID '0', which has a super-short encoding
", "time": "2023-07-26T17:43:16Z"}, {"author": "Eric Orth", "text": "People are going to run a library that encodes everything in a string, so lowercasing the result is only trivial if the entire string needs to be lower cased.
", "time": "2023-07-26T17:45:30Z"}, {"author": "Eric Orth", "text": "everything in a string that needs to be encoded
", "time": "2023-07-26T17:45:51Z"}, {"author": "Julian Reschke", "text": "nope - that library would need to be SF specific
", "time": "2023-07-26T17:46:14Z"}, {"author": "Austin Wright", "text": "3986 suggests normalizing pct-encoded as uppercase
", "time": "2023-07-26T17:48:09Z"}, {"author": "David Schinazi", "text": "re: switching unprompted auth to exported authenticators, I've filed an issue if anyone wants to follow along https://github.com/httpwg/http-extensions/issues/2604
", "time": "2023-07-26T17:48:09Z"}, {"author": "Marco Munizaga", "text": "@Jonathan Hoyland You mentioned some reference you had around the security issues when signing a timestamp as a nonce. Could you please provide me a link? I'd like to read it. Thanks
", "time": "2023-07-26T17:49:14Z"}, {"author": "Benjamin Kaduk", "text": "have to be compatible with SF types currently defined, even
", "time": "2023-07-26T17:49:15Z"}, {"author": "Martin Thomson", "text": "@Benjamin Kaduk yeah, it's the SF types version _as captured in the definition of the field in question_
", "time": "2023-07-26T17:59:36Z"}, {"author": "Watson Ladd", "text": "Why do intermediaries need to decide and reencode things they don't know about vs pass them on?
", "time": "2023-07-26T18:00:32Z"}, {"author": "David Benjamin", "text": "Should we perhaps park retrofit until we've got a concrete use case to design towards, such as the binary encoding? That would help with these details.
", "time": "2023-07-26T18:00:54Z"}, {"author": "Jonathan Hoyland", "text": "Benjamin Kaduk said:
\n\n\nJonathan Hoyland said:
\n\n\nBenjamin Kaduk said:
\n\n\n(Also, in the JOSE/COSE/etc. world key IDs are explicitly not unique and can map to multiple different keys.)
\nOk, that's gonna break _all_ my proofs. This is terrifying.
\nI mean, everybody wants their key to use the key ID '0', which has a super-short encoding
\n
As long as each server only associates key_id 0 with a single key_id that's fine. The issue is the server accepting key_1 and key_2 when given key_id1
", "time": "2023-07-26T18:02:51Z"}, {"author": "Jonathan Hoyland", "text": "Marco Munizaga said:
\n\n\nJonathan Hoyland You mentioned some reference you had around the security issues when signing a timestamp as a nonce. Could you please provide me a link? I'd like to read it. Thanks
\n
The trivial attack works, where a malicious server forwards the header to an honest header.
", "time": "2023-07-26T18:03:31Z"}, {"author": "Jonathan Hoyland", "text": "@Mike Bishop For the notes, were your comments at the mic line in reference to QUERY or Alt-Svc? (\"We want implementations\" could be either)
", "time": "2023-07-26T18:05:48Z"}, {"author": "Jonathan Hoyland", "text": "How does this interact with connection coalescing?
", "time": "2023-07-26T18:10:24Z"}, {"author": "Marco Munizaga", "text": "Jonathan Hoyland said:
\n\n\nMarco Munizaga said:
\n\n\nJonathan Hoyland You mentioned some reference you had around the security issues when signing a timestamp as a nonce. Could you please provide me a link? I'd like to read it. Thanks
\nThe trivial attack works, where a malicious server forwards the header to an honest header.
\n
Right, that makes sense. I was thinking about a case where a client signs timestamp+SNI used for the TLS session. I think that avoids the mitm attack. There's still a replay attack window here. But I'm curious if there's another vulnerability here. For the record, I agree it would be better to use the keying material exporter as the nonce.
", "time": "2023-07-26T18:10:42Z"}, {"author": "Jonathan Hoyland", "text": "Marco Munizaga said:
\n\n\nJonathan Hoyland said:
\n\n\nMarco Munizaga said:
\n\n\nJonathan Hoyland You mentioned some reference you had around the security issues when signing a timestamp as a nonce. Could you please provide me a link? I'd like to read it. Thanks
\nThe trivial attack works, where a malicious server forwards the header to an honest header.
\nRight, that makes sense. I was thinking about a case where a client signs timestamp+SNI used for the TLS session. I think that avoids the mitm attack. There's still a replay attack window here. But I'm curious if there's another vulnerability here. For the record, I agree it would be better to use the keying material exporter as the nonce.
\n
So there's the forward proxy case, which depending on your threat model is an attack or a feature. The problem is that model checking tools will throw up the first vuln they find, which doesn't mean other ones exist. So you can't just say \"we don't care about that attack\" without also saying \"we don't need a security proof\". (Modulo rewriting your security properties to carefully carve out that case.)
", "time": "2023-07-26T18:13:24Z"}, {"author": "Kazuho Oku", "text": "I think the numbers for DNS and SETTINGS are the opposite?
", "time": "2023-07-26T18:14:06Z"}, {"author": "Benjamin Kaduk", "text": "Thinking about websockets reminds me of something rather off-topic for here, but maybe I can mention my data and get follow-ups in unicast: chrome seems to exhibit curious behavior with respect to sending cookies over websocket connections. In particular, if I disable all cookies by default, and then add exceptions to be able to send cookies to specific servers, I think I have to put an exception in with no scheme (so, just \"[.]site.com\" rather than \"httpsL//[.]site.com\") -- neither the \"https\" scheme nor \"wss\" would enable sending cookies on the websocket connection.
\nIf you want to test for yourself, slack is a pretty straightforward thing to test with -- it won't auto-update with new messages (and will warn you it's out of date) if the websocket connection fails.
What's the name of the chap who just took the mike?
", "time": "2023-07-26T18:16:16Z"}, {"author": "Alan Frindell", "text": "That was MT
", "time": "2023-07-26T18:16:30Z"}, {"author": "Benjamin Kaduk", "text": "aka Martin Thomson
", "time": "2023-07-26T18:16:59Z"}, {"author": "Juliusz Chroboczek", "text": "ty
", "time": "2023-07-26T18:17:09Z"}, {"author": "Juliusz Chroboczek", "text": "I must be missing some background, but why the empty Barbie box?
", "time": "2023-07-26T18:20:59Z"}, {"author": "Kazuho Oku", "text": "SETTINGS had the highest score (if you calculate correctly), I do not see why the conclusion of the presentation recommended DNS.
", "time": "2023-07-26T18:22:45Z"}, {"author": "Erik Nygren", "text": "At least for H2, another option might be a flag on the ORIGIN frame. (alas the H3 ORIGIN frame doesn't allow flags)
", "time": "2023-07-26T18:22:47Z"}, {"author": "Kazuho Oku", "text": "I'm concerned if we have been given correct information to discuss.
", "time": "2023-07-26T18:23:10Z"}, {"author": "Erik Nygren", "text": "But extensible per-Origin settings mechanism for H2/H3 might be an option?
", "time": "2023-07-26T18:23:50Z"}, {"author": "Evert Pot", "text": "++ on Ben's idea
", "time": "2023-07-26T18:24:24Z"}, {"author": "Benjamin Kaduk", "text": "@Kazuho Oku SETTINGS must be per-connection, but with coalescing you can get bad data
", "time": "2023-07-26T18:24:58Z"}, {"author": "David Benjamin", "text": "The coalescing problem only exists if you believe this version-dependent baseline is a valid state in the first place. :-)
", "time": "2023-07-26T18:26:43Z"}, {"author": "Watson Ladd", "text": "+1 to it being bad to not have them all work
", "time": "2023-07-26T18:27:36Z"}, {"author": "David Benjamin", "text": "I do think defining h2.1 and h3.1 ALPNs is probably the best way out of this transitory mistake, but this is Controversial. :-) I am also happy with \"WebSockets is not worth the energy\".
", "time": "2023-07-26T18:28:21Z"}]![https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2F8Jww0ZIXMZoXu%2Fgiphy.gif&f=1&nofb=1&ipt=001b8d875fde1a5843ceb4b6bfbac0512a68ff42dd1a9ead4fdae4dd07a188ed&ipo=images](\"https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2F8Jww0ZIXMZoXu%2Fgiphy.gif&f=1&nofb=1&ipt=001b8d875fde1a5843ceb4b6bfbac0512a68ff42dd1a9ead4fdae4dd07a188ed&ipo=images\"){kind=link}