Hi everyone!
", "time": "2023-11-10T12:00:50Z"}, {"author": "Ted Hardie", "text": "The iana registry has quite a few patch-specific media types. Is there any of those which look close to this?
", "time": "2023-11-10T12:12:07Z"}, {"author": "Ted Hardie", "text": "https://www.iana.org/assignments/media-types/media-types.xhtml
", "time": "2023-11-10T12:12:16Z"}, {"author": "Ted Hardie", "text": "Have the authors reached out to the media types list and asked? They'd have to approve a new one, and there may be some guidance there on when it is needed or not.
", "time": "2023-11-10T12:15:03Z"}, {"author": "Julian Reschke", "text": "\"empty PATCH request\"? please no.
", "time": "2023-11-10T12:19:32Z"}, {"author": "Mike Bishop", "text": "What's the logic for not using a partial PUT for the resumption pass? When we're not describing the change, just appending, that seems pretty much on point.
", "time": "2023-11-10T12:19:46Z"}, {"author": "Mike Bishop", "text": "If the initial PUT hasn't really \"completed\" yet, the resource arguably doesn't exist yet to PATCH.
", "time": "2023-11-10T12:20:34Z"}, {"author": "Mike Bishop", "text": "Proxy could do \"Expect: 100-continue\" to the backend to ensure the upload will be accepted, maybe?
", "time": "2023-11-10T12:25:02Z"}, {"author": "Ted Hardie", "text": "How does the upload offset calculation interact with transfer encoding/compression? I'm reporting how many bytes came through the network, is that right?
", "time": "2023-11-10T12:29:39Z"}, {"author": "Marius Kleidl", "text": "Ted Hardie said:
\n\n\nHave the authors reached out to the media types list and asked? They'd have to approve a new one, and there may be some guidance there on when it is needed or not.
\n
I have looked at the media types list and all patch format that I found where specific for JSON, XML etc. However, I will ask on their list for more guidance, thank you.
", "time": "2023-11-10T12:38:01Z"}, {"author": "Julian Reschke", "text": "Marius: IMHO advice from this WG will be as good as it gets
", "time": "2023-11-10T12:38:43Z"}, {"author": "Marius Kleidl", "text": "Mike Bishop said:
\n\n\nWhat's the logic for not using a partial PUT for the resumption pass? When we're not describing the change, just appending, that seems pretty much on point.
\n
Partial PUT is also an option, yes. I am a bit hesitant because the spec mentions issues with backwards compatibility of partial PUT. This might not be a concern in our case though.
", "time": "2023-11-10T12:43:09Z"}, {"author": "Marius Kleidl", "text": "Ted Hardie said:
\n\n\nHow does the upload offset calculation interact with transfer encoding/compression? I'm reporting how many bytes came through the network, is that right?
\n
From a server's perspective, the offset is calculated after Transport-Encoding is applied to decode the request body, however before Content-Encoding is used for decoding.
", "time": "2023-11-10T12:44:41Z"}, {"author": "Ted Hardie", "text": "Thanks for the clarification on that, Marius.
", "time": "2023-11-10T12:45:00Z"}, {"author": "Lucas Pardue", "text": "Ted Hardie said:
\n\n\nHow does the upload offset calculation interact with transfer encoding/compression? I'm reporting how many bytes came through the network, is that right?
\n
to my mind HTTP uploads are acting on representations. Content-encoding is tied to representations but transfer-encoding is not. Also, transfer-encoding is not a thin in HTTP/2 or HTTP/3. In other words, the server is receiving bytes of the representation (however it gets that).
\nHowever, we probably would benefit from some text to discuss how HTTP/1.1 transfer-encoding might be a footgun if the server counted those bytes naiively. I created an issue so we don't forget https://github.com/httpwg/http-extensions/issues/2679
", "time": "2023-11-10T12:45:16Z"}, {"author": "Marius Kleidl", "text": "Thanks for the feedback, Ted and Lucas. We should clarify this in the draft.
", "time": "2023-11-10T12:46:19Z"}, {"author": "Alan Frindell", "text": "Now remembering that my thought at 117 is we should explore issuing guidance to move away from HTTP/1.1.
", "time": "2023-11-10T12:46:58Z"}, {"author": "Mike Bishop", "text": "Marius Kleidl said:
\n\n\nPartial PUT is also an option, yes. I am a bit hesitant because the spec mentions issues with backwards compatibility of partial PUT. This might not be a concern in our case though.
\n
I think if this draft mandates the use of partial PUT, one could safely take explicit indications of support for resumable upload as agreement to accept partial PUT.
", "time": "2023-11-10T12:47:38Z"}, {"author": "Marius Kleidl", "text": "Good point. Thank you, Mike. We will consider this as an alternative to using PATCH.
", "time": "2023-11-10T12:51:34Z"}, {"author": "Mike Bishop", "text": "@Benjamin Schwartz, I think what you missed was Kazuho saying this draft MUST be adopted because of the flaw in CONNECT-UDP.
", "time": "2023-11-10T12:52:50Z"}, {"author": "Eric Orth", "text": "Hmmmmmm.
", "time": "2023-11-10T12:53:58Z"}, {"author": "Mike Bishop", "text": "Note that the PRI method was registered by 7540 for that reason -- if a server interpreted the preamble as HTTP, the method would never be valid.
", "time": "2023-11-10T12:55:05Z"}, {"author": "Alan Frindell", "text": "PTTH
", "time": "2023-11-10T12:55:36Z"}, {"author": "David Schinazi", "text": "lol
", "time": "2023-11-10T12:55:42Z"}, {"author": "Kazuho Oku", "text": "@Benjamin Schwartz My comment was +1 to adopt, and as a mitigation, the only thing we need to say is don't send optimistically in H1, because we aren't interested in optimizing it any more.
", "time": "2023-11-10T12:56:36Z"}, {"author": "Mark Nottingham", "text": "Intermediaries are clients too!
", "time": "2023-11-10T12:58:23Z"}, {"author": "Ted Hardie", "text": "Ben, you keep talking about the state of the art, but what you propose was largely built in 2000; see https://www.slideserve.com/noah/bellwether-surrogate-services-for-popular-content-powerpoint-ppt-presentation . \"surrogate\" was an old name for a class of reverse proxy.
", "time": "2023-11-10T13:04:04Z"}, {"author": "Pete Resnick", "text": "There are also a bunch of approaches to solve these sorts of problems in different layers (DDNS, NAT traversal, etc.). I wouldn't think this is interesting to do unless Cloudflare, Apple, and others who are already doing this express a need and desire to do something standard.
", "time": "2023-11-10T13:06:31Z"}, {"author": "Lucas Pardue", "text": "is kazuho suggesting HTTP over WebTransport? :D
", "time": "2023-11-10T13:09:57Z"}, {"author": "Alan Frindell", "text": "Lucas Pardue said:
\n\n\nis kazuho suggesting HTTP over WebTransport? :D
\n
Ben mentioned the state of the art implementations are HTTP over websockets, so why not?
", "time": "2023-11-10T13:12:24Z"}, {"author": "Mark Nottingham", "text": "https://github.com/cloudflare/cloudflared
", "time": "2023-11-10T13:15:59Z"}, {"author": "David Schinazi", "text": "so much enthusiasm today
", "time": "2023-11-10T13:18:35Z"}, {"author": "Erik Nygren", "text": "Lots of enthusiasm enthusiasts.
", "time": "2023-11-10T13:18:52Z"}, {"author": "Pete Resnick", "text": "I'm summarily unenthusiastic today.
", "time": "2023-11-10T13:19:04Z"}, {"author": "Jonathan Lennox", "text": "More than I'd expect on an IETF Friday
", "time": "2023-11-10T13:19:10Z"}, {"author": "Alan Frindell", "text": "I'm a flying home soon enthusiast
", "time": "2023-11-10T13:19:18Z"}, {"author": "David Schinazi", "text": "this is getting out of hand :rolling_on_the_floor_laughing:
", "time": "2023-11-10T13:19:40Z"}, {"author": "Mark Nottingham", "text": "David, you're not an enthusiast enthusiast?
", "time": "2023-11-10T13:20:04Z"}, {"author": "Alan Frindell", "text": "Too late to put the genie back in the bottle David. You started a movement. Own it.
", "time": "2023-11-10T13:20:13Z"}, {"author": "Philipp Tiesel", "text": "Alan Frindell said:
\n\n\nLucas Pardue said:
\n\n\nis kazuho suggesting HTTP over WebTransport? :D
\nBen mentioned the state of the art implementations are HTTP over websockets, so why not?
\n
Because you end up with a clunky form of multiplexing on to. Yay, worked fine for the last 10 years, but teams are currently looking for something more lightweight.
", "time": "2023-11-10T13:22:17Z"}, {"author": "Mike Bishop", "text": "There have been similar attempts in the past. For example, this looks somewhat similar to https://datatracker.ietf.org/doc/draft-xie-bidirectional-messaging/, co-authored by @Alan Frindell . Also note https://datatracker.ietf.org/doc/html/draft-lentczner-rhttp-00, which uses Upgrade to flip an H1 connection to the opposite direction.
", "time": "2023-11-10T13:22:34Z"}, {"author": "Philipp Tiesel", "text": "I am not confident the the current idea is the right solution, but I guess we should do something for the reverse http usecase.
\nMASQ listen HTTP could also be an option.
or CONNECT-IP if the origin is on a different box than \"translator\"
", "time": "2023-11-10T13:25:01Z"}, {"author": "Mike Bishop", "text": "Yeah, I'm intrigued by the possibility of CONNECT-{TCP,UDP} where you get a port in 127.x.x.x space and the server knows where to find the origin you advertised.
", "time": "2023-11-10T13:25:13Z"}, {"author": "Pete Resnick", "text": "There was not a hand-raising exercise for the previous doc. Was that because adoption was not yet requested?
", "time": "2023-11-10T13:25:51Z"}, {"author": "Tommy Pauly", "text": "Yeah the last one is still early in development
", "time": "2023-11-10T13:26:08Z"}, {"author": "Jonathan Lennox", "text": "MASQUE listen UDP+conversion to forwarding mode?
", "time": "2023-11-10T13:26:11Z"}, {"author": "Mike Bishop", "text": "It certainly avoids the concern that an attacker can see the other side of the connection!
", "time": "2023-11-10T13:26:39Z"}, {"author": "Benjamin Schwartz", "text": "The Reverse HTTP draft actually does propose using MASQUE in some scenarios ... perhaps not in the way some here are imagining though.
", "time": "2023-11-10T13:26:57Z"}, {"author": "Kazuho Oku", "text": "Re if masque is appropriate for rhttp, I kind of believe that it depends on what you need ... people prefer using L2, L3, L4, L7 solutions for different reasons, even masque has connect-ethernet, connect-ip, connect-tcp/udp, ordinary HTTP being L7.
\nThat'd be the case for rhttp as well. Some may prefer VPN-like solution, some might prefer application level.
Personally, my interest would be having an optimized solution, so turning an connect-rhttp upgrade on H1 makes the most sense.
(because you'd get a raw TLS socket on which you can send HTTP on the opposite direction)
", "time": "2023-11-10T13:29:28Z"}, {"author": "Alan Frindell", "text": "Mike Bishop said:
\n\n\nThere have been similar attempts in the past. For example, this looks somewhat similar to https://datatracker.ietf.org/doc/draft-xie-bidirectional-messaging/, co-authored by Alan Frindell . Also note https://datatracker.ietf.org/doc/html/draft-lentczner-rhttp-00, which uses Upgrade to flip an H1 connection to the opposite direction.
\n
Yeah, we brought that right when WebTransport was taking off, and decided to hitch our wagon there instead of pursuing the bidirectional thing. It was also slightly different since sending a request from the server->client required the equivalent of a webtransport connect stream in order to route it through a proxy.
", "time": "2023-11-10T13:31:59Z"}, {"author": "Mike Bishop", "text": "@Jonathan Hoyland , you're missing that this version entirely drops the prompted form of EA, so there is actual protocol work that can be omitted.
", "time": "2023-11-10T13:32:44Z"}, {"author": "Jonathan Hoyland", "text": "OK, so I missed the DNS check thing, can I rejoin the queue on that topic?
", "time": "2023-11-10T13:33:39Z"}, {"author": "Lucas Pardue", "text": "sorry but I strongly disagree that adding client certs now is cheaper. I don't want client implementations to be put off from implementing a spec because they have to opt in to two things when they only want to benefit from one. And making one document allow opting into different features slows down the standards process
", "time": "2023-11-10T13:34:47Z"}, {"author": "Tommy Pauly", "text": "Jonathan can you take to chat?
", "time": "2023-11-10T13:35:11Z"}, {"author": "Jonathan Hoyland", "text": "We did some research on ORIGIN Frames and found that including the DNS check pretty much removed all performance improvements
", "time": "2023-11-10T13:35:49Z"}, {"author": "Benjamin Schwartz", "text": "@Lucas Pardue If a client doesn't want to use secondary client certs, does that actually add complexity for them? I would think that including secondary client certs would increase _server_ implementation complexity.
", "time": "2023-11-10T13:36:29Z"}, {"author": "Jonathan Hoyland", "text": "The DNS checks also made it very difficult to deploy at Cloudflare, because we have lots of different IPs operating from the same metals.
", "time": "2023-11-10T13:36:43Z"}, {"author": "Jonathan Hoyland", "text": "We had to go from a flexible IP model to a rigid \"you must use this IP\" model to run the experiment.
", "time": "2023-11-10T13:37:11Z"}, {"author": "Jonathan Hoyland", "text": "IPs should only be used to route traffic, and not to provide identity.
", "time": "2023-11-10T13:39:00Z"}, {"author": "Lucas Pardue", "text": "Ben to clarify: my point is if we had RFC NNNN, that defined a single extension for client and server certs, the HTTP library will have to do the work for both sides. If we split it into two extensions in one doc, we might as well just split the docs IMO
", "time": "2023-11-10T13:39:29Z"}, {"author": "Erik Nygren", "text": "That is my concern: if there are no performance improvements when we do the DNS check, and if secondary server certs without the DNS check introduces a while range of new attack surfaces, it seems like we are stuck with either: 1) adding a bunch of complexity for little benefit; or 2) having to walk back on the DNS check and then have a bunch of new and concerning attack surfaces.
", "time": "2023-11-10T13:40:42Z"}, {"author": "Lucas Pardue", "text": "there are some client-only and server-only libs/stacks of course
", "time": "2023-11-10T13:40:42Z"}, {"author": "Benjamin Schwartz", "text": "@Jonathan Hoyland Easy, we make an HTTPS record flag like \"dns-match-opt-out\" :innocent:
", "time": "2023-11-10T13:41:22Z"}, {"author": "Jonathan Hoyland", "text": "@Erik Nygren That presupposes that the only possible benefits are performance ones. Coalescing provides improved privacy benefits too.
", "time": "2023-11-10T13:41:47Z"}, {"author": "Jonathan Hoyland", "text": "But secondly, I'm not sure where this extra attack surface is. If an attacker can get a cert issued and can bypass CT, then honestly you're toast.
", "time": "2023-11-10T13:43:18Z"}, {"author": "Erik Nygren", "text": "Benjamin Schwartz said:
\n\n\nJonathan Hoyland Easy, we make an HTTPS record flag like \"dns-match-opt-out\" :innocent:
\n
That might be reasonable. It's not as much the IPs that matter as much as having a second factor that makes it harder for someone who compromises a certificate (through misissuance or loss) to use it for attacking users.
", "time": "2023-11-10T13:44:32Z"}, {"author": "Benjamin Schwartz", "text": "(This would delete the second factor...)
", "time": "2023-11-10T13:46:48Z"}, {"author": "Jonathan Hoyland", "text": "Benjamin Schwartz said:
\n\n\nJonathan Hoyland Easy, we make an HTTPS record flag like \"dns-match-opt-out\" :innocent:
\n
If an attacker can control the IP then they can also set dns-match-opt-out, no?
Exactly, any attacker who can set this flag can also modify the DNS, so it's \"secure\". BUT, setting it reduces your security, because anyone who steals your key can capture your users via Secondary Certificates, without DNS or transport interference.
", "time": "2023-11-10T13:49:09Z"}, {"author": "Benjamin Schwartz", "text": "I love WebDAV!
", "time": "2023-11-10T13:53:39Z"}, {"author": "Benjamin Schwartz", "text": "https://datatracker.ietf.org/doc/html/rfc4918
", "time": "2023-11-10T13:54:21Z"}, {"author": "Julian Reschke", "text": "there's versioning as well
", "time": "2023-11-10T13:54:55Z"}, {"author": "Erik Nygren", "text": "The primary attack of concern is that attacker gets a certificate for origin A. They operate server B (eg, a phishing site, a subresource they get included in advertiseements, etc) and get lots of users to connect to it. They then send the secondary cert for A and get the user to issue a request to https://A (eg, as a 30x redirect or a subresource from something on B) and then do attacks against resources on origin A. While this class of attack is entirely possible today on-path (eg, if the attacker controls DNS or controls the users local network, etc) then it is already game-over today, Secondary Certs without a second factor control via DNS opens up this class of attacks to be remote and from anyone on the Internet.
", "time": "2023-11-10T13:55:39Z"}, {"author": "Benjamin Schwartz", "text": "Also, making key theft attacks easier to execute increases the incentive to steal keys, so we don't really know how common this kind of attack might become.
", "time": "2023-11-10T13:56:54Z"}, {"author": "Jonathan Hoyland", "text": "I don't have a problem with adding more security to connections in general, but relying on IP for identity is just wrong.
", "time": "2023-11-10T13:57:34Z"}, {"author": "K\u00e9vin Dunglas", "text": "Mercure: https://mercure.rocks/spec
", "time": "2023-11-10T13:57:40Z"}, {"author": "Erik Nygren", "text": "The SvcParam for a \"dns-match-opt-out\" at least allows origins to claim that they don't care about this class of attack. (ie, it is \"enable-remote-impersonation-with-cert\" which might be a reasonable trade-off for some uses)
", "time": "2023-11-10T13:58:00Z"}, {"author": "Alan Frindell", "text": "I think having a better story around standardizing pub/sub interactions over HTTP is a good thing. We've done a lot of pub/sub work over in moq, and I've given some thought about what the gap is there -- why HTTP can't suffice natively.
", "time": "2023-11-10T13:58:21Z"}, {"author": "Kazuho Oku", "text": "Agreed. And the argument might be that HTTP deals with resources, having resource-level notification system inside HTTP might make things simpler.
", "time": "2023-11-10T13:59:15Z"}, {"author": "Jonathan Hoyland", "text": "@Erik Nygren Maybe a better option is a list of SANs that can be coalesced?
", "time": "2023-11-10T13:59:59Z"}, {"author": "Jonathan Hoyland", "text": "Or a range of IPs that you can coalesce to.
", "time": "2023-11-10T14:00:30Z"}, {"author": "Erik Nygren", "text": "Sharing the same CNAME target or same SVCB TargetName (which the latest draft seems to be allowing) might also be reasonable. If the ORIGIN frame comes along with the secondary cert then \"same IP\" may not be necessary. (I'm also not a fan of relying on IP for identity)
", "time": "2023-11-10T14:00:31Z"}, {"author": "Jonathan Hoyland", "text": "ORIGIN Frame says use IP in the h2c case, or optionally always.
", "time": "2023-11-10T14:01:11Z"}, {"author": "Benjamin Schwartz", "text": "Another problem with all of this is that you still need to wait for the DNS query before you can use the Secondary Certificate
", "time": "2023-11-10T14:01:47Z"}, {"author": "Jonathan Hoyland", "text": "Not if the DNS query is on the first domain, as opposed to checking the IP of the second domain
", "time": "2023-11-10T14:02:16Z"}, {"author": "Erik Nygren", "text": "Yes, a SvcParam that lists which \"you can coalesce onto any of this list of SANs with a secondary cert from them as the primary\" would also address this and could be a better solution that just an opt-out.
", "time": "2023-11-10T14:02:18Z"}]