IETF
httpbis
httpbis@jabber.ietf.org
Monday, November 7, 2022< ^ >
Martin Thomson has set the subject to: https://github.com/httpwg/wg-materials/blob/gh-pages/interim-20-05/agenda.md
https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-httpbis-01-httpbis?useMonospaceFont=true
Room Configuration
Room Occupants

GMT+0
[15:24:38] <zulipbot> (Julian Reschke) Moin.
[15:25:17] <zulipbot> (Francesca Palombini) hello! What a nice ceiling
[15:32:41] <zulipbot> (Henry Story) the room is pretty empty or is the camera pointing the wrong direction?
[15:36:04] npd joins the room
[15:36:24] npd leaves the room
[15:38:37] sftcd joins the room
[15:40:57] zulipbot leaves the room
[15:47:31] sftcd leaves the room
[15:47:44] zulipbot joins the room
[15:48:15] <zulipbot> (Justin Richer) @**Julian Reschke** I think the text on query is clear: The value is normalized according to the rules in [HTTP], Section 4.2.3. Namely, percent-encoded octets are decoded.
[15:48:45] <zulipbot> (Justin Richer) and path has this: Namely, an empty path string is normalized as a single slash / character, and path components are represented by their values after decoding any percent-encoded octets.
[15:48:59] <zulipbot> (Tommy Pauly) @Martin good reference =)
[15:49:45] <zulipbot> (Julian Reschke) @justin: the problem here is that you loose information if you decode percent-encoded resevred characters
[15:50:00] <zulipbot> (Justin Richer) @**Julian Reschke** What's the issue of combined field values? Is this the thing about spaces in between values?
[15:50:13] <zulipbot> (Julian Reschke) @justin: yep
[15:50:39] <zulipbot> (Justin Richer) @**Julian Reschke** why would you lose information?
[15:50:52] <zulipbot> (Nick Doty) every "slides" link in the agenda is broken
[15:51:06] <zulipbot> (Julian Reschke) necause a "/" in a path has special meaning
[15:51:06] <zulipbot> (Nick Doty) the minutes link in the agenda is incorrect
[15:51:19] <zulipbot> (Nick Doty) the chatroom link in the agenda is missing
[15:51:19] <zulipbot> (Daniel Gillmor) stickiness from Alt-Svc is another cookie-equivalent too, from a privacy perspective.
[15:51:32] <zulipbot> (Tommy Pauly) The minutes link is updated
[15:51:32] <zulipbot> (Julian Reschke) buet let's take that to the mailing list then
[15:51:46] <zulipbot> (Justin Richer) @**Julian Reschke** but you don't use the value from the signature base outside the signature.
[15:52:03] <zulipbot> (Julian Reschke) @justin: there are semantically different values that will have the same signature
[15:53:20] <zulipbot> (Justin Richer) @**Julian Reschke** from a security perspective I'd prefer to keep it without any decoding, ie "just use it as it comes in", but we were trying to apply whatever teh common transforms to this data would be. So if I call "request.getQuery()" what do I get out of it?
[15:54:30] <zulipbot> (Julian Reschke) @justin: at least in Java you always have access to the raw request URI. Dunno about other platforms
[15:54:45] <zulipbot> (Justin Richer) @**Julian Reschke** what is your suggested solution?
[15:55:55] <zulipbot> (Julian Reschke) either require signing the raw parts, or document the issue and explain why the ambiguity is ok
[15:57:23] <zulipbot> (Justin Richer) My preference is to sign the raw path and query, but I'd like to see what Annabelle and others think of this.
To the other issue: The combination/spaces issue needs to have some warning text, which we're planning to add.
[15:58:04] <zulipbot> (Julian Reschke) ok
[15:58:17] <zulipbot> (Henry Story) I can try to find out what various scala libs return if you give us an full http message example. (not sure where you'd put that?)
[15:59:59] <zulipbot> (Henry Story) I put up a zulip channel for http sig https://zulip.ietf.org/#narrow/stream/225-httpbis/topic/Signing.20HTTP.20Messages
[16:01:54] <zulipbot> (Nick Doty) per dkg, it seems like there's a risk that sticky alt services will get used as cookies/etag replacement, which might discourage clients from using them
[16:02:33] <zulipbot> (Eric Orth) Tommy Pauly: If you want my opinion on bespoke host resolution APIs.  It comes up occassionally, but I'd really prefer to avoid using any host resolution APIs unless standardized between OSs.
[16:02:33] <zulipbot> (Eric Kinnear) @**David Schinazi** I'd say it turned out to be as tricky as expected :D
[16:03:12] <zulipbot> (David Schinazi) thx Valentin
[16:04:45] <zulipbot> (Eric Orth) If we had a getaddrinfo2() that all the big OSs agreed on, Chrome could probably use that in more cases, but until then, bespoke APIs only come up for the usecases of "if there's absolutely nothing else we can do and no more improvements we could make to our built-in resolver to do what we need to do".
[16:05:56] <zulipbot> (Daniel Gillmor) i think getaddrinfo2 would be a huge contribution to getting all the DNS hotness in a deployable state
[16:06:09] <zulipbot> (Jonathan Lennox) There's unfortunately a big conflict between the application requirement for "I need this DNS record" vs. the OS requirement for "I need to support these eighteen legacy hostname lookup methods."
[16:06:37] <zulipbot> (Daniel Gillmor) the OS can retain those legacy hostname lookup records without blocking a getaddrinfo2
[16:06:50] <zulipbot> (Daniel Gillmor) so i don't see the conflict
[16:07:03] <zulipbot> (Jonathan Lennox) But should a getaddrinfo2 lookup use them?  For just A/AAAA record requests, or for other things too?
[16:07:03] <zulipbot> (Justin Richer) but the question is which one do you call
[16:07:29] <zulipbot> (Daniel Gillmor) the application layer calls the one that gives it the data it needs
[16:07:29] <zulipbot> (Jonathan Lennox) getaddrinfo vs. getaddrinfo2 giving different answers would be bad
[16:07:42] <zulipbot> (Martin Thomson) Unicode also has flags in the same way
[16:08:01] <zulipbot> (Martin Thomson) we made a bunch of bad choices in the past...
[16:08:14] <zulipbot> (Martin Thomson) move the flags to the frame type
[16:08:27] <zulipbot> (Martin Thomson) just the mandatory ones
[16:08:28] <zulipbot> (Jonathan Lennox) 🏳
[16:11:00] <zulipbot> (Martin Thomson) 🦵🥫🛣️
[16:14:00] <zulipbot> (David Schinazi) I'd suggest adding a line to explain that the h3 version doesn't have flags for future us
[16:14:13] <zulipbot> (Bron Gondwana) draft-nottingham-undeprecate-humming
[16:15:27] <zulipbot> (Erik Nygren) +1 to David
[16:19:42] <zulipbot> (Jonathan Lennox) Go to SHMOO and figure out how to do humming in hybrid meetings...
[16:20:15] <zulipbot> (Nick Doty) there seemed to be agreement on "layering" that it would be great to have a more coordinated set-up for what is in the cookie spec and what is elsewhere
[16:20:16] <zulipbot> (Nick Doty) but I'm not clear on what the direction is, besides that someone oughta do it
[16:20:55] <zulipbot> (Martin Thomson) the proposed direction is that we not hold the current document up for that work, but do that in the *next* revision
[16:31:32] <zulipbot> (Daniel Gillmor) wait, the bit would be harmful because there is a use case for it being *set*?
[16:37:07] <zulipbot> (Randell Jesup) +1 to Martin; glad to see this
[16:37:37] <zulipbot> (Daniel Gillmor) agreed with the current speaker -- if the server can specify it, it implies that the server can decline it
[16:38:25] <zulipbot> (Daniel Gillmor) why do they need this explicit signal to migrate?
[16:40:59] <zulipbot> (Nick Doty) it should help migration by letting some sites try it out early with some of their cookies
[16:42:36] <zulipbot> (Daniel Gillmor) can't those sites try it out already with browsers that already partition?
[16:42:49] <zulipbot> (Nick Doty) "this is fine, not great" :)
[16:42:50] <zulipbot> (Daniel Gillmor) or just a flag in the browser, that the developers who care can turn on?
[16:43:24] <zulipbot> (Daniel Gillmor) (the developers who don't care won't set the flag on the cookies either)
[16:43:37] <zulipbot> (Benjamin Schwartz) It seems like it would be helpful to have a way to audit your vast collection of microservices to figure out which ones are partitioning-ready
[16:43:50] <zulipbot> (Daniel Gillmor) how does this help with an audit?
[16:44:20] <zulipbot> (Benjamin Schwartz) You can measure compliance from your server logs.
[16:45:27] <zulipbot> (Henry Story) I have been waiting for a while for the ability to pass client certs throught http...
[16:45:53] <zulipbot> (Daniel Gillmor) so, aiui, the audit process is: site sets "partitioned" on every cookie it emits, then investigate server logs to see... what?
[16:46:19] <zulipbot> (Henry Story) Can one also pass other types of Ceritficates in that header?
[16:47:16] <zulipbot> (Benjamin Schwartz) @**Daniel Gillmor** The process is: you call all your vendors or eng teams and tell them that you want their stuff partitioning-ready by EOY 2023, and to set the Partition flag on their cookies when they are ready.  Then you make a graph of what fraction of cookies have the flag, and if the line isn't going up and to the right, you see who's late and go yell at them.
[16:48:34] <zulipbot> (Daniel Gillmor) so this is a flag for communicating between vendors and project managers by way of server logs
[16:49:36] <zulipbot> (Martin Thomson) So Justin, are you saying that we can fix problems with one terrifying spec by applying another terrifying spec?
[16:49:36] <zulipbot> (Nick Doty) I think the process is, we're pretty sure this service will work with partitioned cookies, we can test it out with all our users by adding a new cookie with the Partitioned attribute, and if we see breakage or we needed to rely on the unpartitioned cookie, we can log the error
[16:50:29] <zulipbot> (Benjamin Schwartz) @**Daniel Gillmor** it's `from __future__ import partitioning`.  Not so different from the work to prepare for the deprecation of Python 2 actually.
[16:51:32] <zulipbot> (Daniel Gillmor) analogies with the python2 → python3 transition are … not confidence inspiring
[16:51:58] <zulipbot> (Benjamin Schwartz) It's not my job, so I can afford to be a realist.
[16:52:12] <zulipbot> (Steven Bingler) > This is an issue because nowadays servers are no longer one entity, and one part may set and another part might not be able to understand them.
Kudos to the note taker for phrasing my point much better than I did
[16:52:25] <zulipbot> (James Gruessing) Masque enthusiast... not wearing a mask.
[16:53:17] <zulipbot> (Henry Story) masks are not mandatory for speakers. I prefer if speakers don't wear masks acutally,  as it is easier to hear them.
[16:53:43] <zulipbot> (James Gruessing) 'twas meant with slight tongue and cheek Henry.
[16:58:26] <zulipbot> (Eric Kinnear) Masque is Wednesday Session I, btw
[17:04:35] <zulipbot> (Henry Story) I wonder if there is any thinking on p2p http
[17:05:09] <zulipbot> (Henry Story) ie. client and server switching roles.
[17:06:08] <zulipbot> (Alex Chernyakhovsky) What do you mean by that? I think in webtrans it's possible for some server-initiated stuff?
[17:06:41] <zulipbot> (Henry Story) I wrote up a lot of links and reasons for why this could be interesting here: https://github.com/w3c/architecture/issues/14
[17:08:35] <zulipbot> (Benjamin Schwartz) "Probing resistance" is the term I use for this.
[17:08:48] <zulipbot> (Alex Chernyakhovsky) I really don't understand what that's trying to say. Is the goal to just allow a client-initiated connection but allow the "server" (i.e., the thing that called accept(2) on the socket) to issue the _client_ HTTP methods...?
[17:09:43] <zulipbot> (Alex Chernyakhovsky) If so ... sure? We can do a LISTEN (per the draft David mentioned) over the initial connection to open up the client to the server fairly easily
[17:10:02] <zulipbot> (Henry Story) yes, so that the server could then do a GET /key1 HTTP/2 to the client after a HTTP Sig request
[17:12:56] <zulipbot> (Henry Story) That would allow clients to publish keys in a non-global environment.
[17:13:09] <zulipbot> (Henry Story) Essentially that is what HTTPS does when the server asks the client for a cert.
[17:14:04] <zulipbot> (Martin Thomson) That is a really long field name.
[17:14:17] <zulipbot> (Martin Thomson) Maybe for this, that's not a big deal.
[17:14:43] <zulipbot> (Alex Chernyakhovsky) How about shortening it to "unauth" :)
[17:19:28] <zulipbot> (Nick Doty) a shibboleth
[17:20:43] <zulipbot> (Martin Thomson) traversing intermediaries is an anti-feature
[17:20:58] <zulipbot> (Martin Thomson) for something like this, that is
[17:21:24] <zulipbot> (David Oliver) @ben bridge distribution is only one use case
[17:22:23] <zulipbot> (Martin Thomson) Dammit Kyle beat me to it
[17:23:07] <zulipbot> (Benjamin Schwartz) @**David Oliver** Sure, can you please describe a use case where the client cannot easily learn a per-origin secret in advance?
[17:23:36] <zulipbot> (Benjamin Schwartz) @**Martin Thomson** No, running confidential services through a CDN is extremely valuable.
[17:24:02] <zulipbot> (Nick Doty) +1 for working on this use case
[17:24:21] <zulipbot> (David Oliver) +1
[17:24:34] <zulipbot> (Benjamin Schwartz) +1
[17:24:48] <zulipbot> (Eric Orth) +1
[17:25:20] <zulipbot> (David Oliver) @ben will ping you later
[17:25:33] <zulipbot> (Benjamin Schwartz) Thanks!
[17:25:53] <zulipbot> (Francesca Palombini) thank you!
[17:26:06] <zulipbot> (Jacob Hatch) Thank you.
[17:26:06] <zulipbot> (Roberto Polli) bye
[17:26:19] <zulipbot> (Tommy Pauly) Thank you all!
[17:26:19] <zulipbot> (Roberto Polli) Thanks everyone!
[17:26:45] <zulipbot> (Henry Story) Thanks. I am hanging around in Zulip here...
[17:27:11] <zulipbot> (Henry Story) I hope to have HttpSig implementation of the latest spec finished by Friday morning.
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!