@Mike Bishop though HTTP/1.1 is probably more likely to operate better with new connections for new certs, it also doesn't have coalescing (at least formally)
", "time": "2023-07-28T00:05:40Z"}, {"author": "Martin Thomson", "text": "s/browser choice /client choice / of course
", "time": "2023-07-28T00:06:48Z"}, {"author": "Martin Thomson", "text": "cruise linear certificates is a nice term
", "time": "2023-07-28T00:08:08Z"}, {"author": "Martin Thomson", "text": "omnibus certificates
", "time": "2023-07-28T00:08:17Z"}, {"author": "Alan Frindell", "text": "Does someone want to build/deploy these \"hybrid proxy\" use cases?
", "time": "2023-07-28T00:08:57Z"}, {"author": "Martin Thomson", "text": "ECH plus plus
", "time": "2023-07-28T00:08:59Z"}, {"author": "Jonathan Hoyland", "text": "Encrypt _all_ the things
", "time": "2023-07-28T00:09:17Z"}, {"author": "Martin Thomson", "text": "I would infer from this that Apple wants to do the hybrid proxy deployment (iCloud Private Relay has forward proxies that are also reverse proxies...)
", "time": "2023-07-28T00:09:42Z"}, {"author": "Martin Thomson", "text": "A setting seems like it might be wise, if only to avoid a whole lot of wasted effort
", "time": "2023-07-28T00:11:28Z"}, {"author": "Martin Thomson", "text": "Though optimistic sending of certificates might help from a performance perspective, so maybe you don't prohibit sending without a setting.
", "time": "2023-07-28T00:11:53Z"}, {"author": "Alan Frindell", "text": "CONTINUATION
", "time": "2023-07-28T00:13:26Z"}, {"author": "Martin Thomson", "text": "I was going to say the same Alan
", "time": "2023-07-28T00:13:44Z"}, {"author": "Martin Thomson", "text": "Confused deputy attacks were part of the threat model that we tried to address with the client side of this, which was why we ended up having identifiers and all that complexity.
", "time": "2023-07-28T00:14:28Z"}, {"author": "Martin Thomson", "text": "^^ is in anticipation of @Jonathan Hoyland's comment.
", "time": "2023-07-28T00:14:51Z"}, {"author": "Martin Thomson", "text": "[will take patches]
", "time": "2023-07-28T00:17:41Z"}, {"author": "Martin Thomson", "text": "not baked
", "time": "2023-07-28T00:18:21Z"}, {"author": "David Schinazi", "text": "I'm in another session so I can't come to the mic but I'm supportive of this work
", "time": "2023-07-28T00:18:59Z"}, {"author": "Watson Ladd", "text": "David Schinazi said:
\n\n\nI'm in another session so I can't come to the mic but I'm supportive of this work
\n
Multitasking enthusiast
", "time": "2023-07-28T00:19:22Z"}, {"author": "Jonathan Hoyland", "text": "We also need a way of agreeing signature algos
", "time": "2023-07-28T00:19:30Z"}, {"author": "David Schinazi", "text": "One might even say enthusiastic
", "time": "2023-07-28T00:19:31Z"}, {"author": "Watson Ladd", "text": "Jonathan Hoyland said:
\n\n\nWe also need a way of agreeing signature algos
\n
Do it twice!
", "time": "2023-07-28T00:19:56Z"}, {"author": "Martin Thomson", "text": "I'm not sure that we need sig-algs support, but I'd like to have that worked out more fully
", "time": "2023-07-28T00:19:57Z"}, {"author": "Martin Thomson", "text": "@Watson Ladd you mean try every certificate and every algorithm?
", "time": "2023-07-28T00:20:15Z"}, {"author": "Watson Ladd", "text": "Wait don't we know client capabilities from the hello?
\nYeah because there's only 2
", "time": "2023-07-28T00:20:28Z"}, {"author": "Watson Ladd", "text": "Or 3
", "time": "2023-07-28T00:20:38Z"}, {"author": "Martin Thomson", "text": "Indeed, there aren't many combinations, so maybe it would work. And for the server the TLS stack should know which ones the client TLS stack has indicated won't work.
", "time": "2023-07-28T00:21:02Z"}, {"author": "Martin Thomson", "text": "This pattern-matching stuff always gives me a chill.
", "time": "2023-07-28T00:21:45Z"}, {"author": "Jonathan Hoyland", "text": "The client only knows one sigalg the server supports. If its cert doesn't match what does it do?
", "time": "2023-07-28T00:22:01Z"}, {"author": "Martin Thomson", "text": "maybe the server could send down a JS function that the client can execute to determine which resources are covered
", "time": "2023-07-28T00:22:22Z"}, {"author": "Jonathan Hoyland", "text": "Martin Thomson said:
\n\n\nThis pattern-matching stuff always gives me a chill.
\n
I thought that was just the ac
", "time": "2023-07-28T00:22:27Z"}, {"author": "Watson Ladd", "text": "Jonathan Hoyland said:
\n\n\nThe client only knows one from the server. If it's cert doesn't match what does it do?
\n
That's where we need full complexity. For unilateral server side where this is only an optimization I don't think we do
", "time": "2023-07-28T00:23:11Z"}, {"author": "Jonathan Hoyland", "text": "I want this with client side too
", "time": "2023-07-28T00:23:55Z"}, {"author": "Martin Thomson", "text": "@Jonathan Hoyland have you looked at the history of the work and the complaints about confused deputy attacks that were raised?
", "time": "2023-07-28T00:24:19Z"}, {"author": "Jonathan Hoyland", "text": "Yeah, I wrote 200 pages of my thesis on it
", "time": "2023-07-28T00:24:52Z"}, {"author": "Mike Bishop", "text": "Shouldn't it vary on content-encoding, not accept-encoding?
", "time": "2023-07-28T00:25:59Z"}, {"author": "Watson Ladd", "text": "I don't understand the slide with the cors
", "time": "2023-07-28T00:26:12Z"}, {"author": "Martin Thomson", "text": "@Alan Frindell , @Felix Handte would changing the URI scheme be feasible at all?
", "time": "2023-07-28T00:29:57Z"}, {"author": "Kazuho Oku", "text": "+1 to adopt.
\nI think my question is why we need all those security precautions, when the combination of algorithm and a prepared dictionary is essentially an unique compression algorithm.
If it is the case that certain types of compression algorithms are more prone to attacks than other, then we should state that in the core docs?
", "time": "2023-07-28T00:30:51Z"}, {"author": "Alan Frindell", "text": "Felix couldn't make it. I'm not authoritative on what is possible with our URI schemes. My hunch is it would be hard.
", "time": "2023-07-28T00:30:59Z"}, {"author": "Felix Handte", "text": "Gut reaction: that's a much larger order of difficulty beyond the abilities of a mere mortal like myself. But in theory, yeah.
", "time": "2023-07-28T00:31:02Z"}, {"author": "Alan Frindell", "text": "Oh you are here. yay!
", "time": "2023-07-28T00:31:14Z"}, {"author": "Felix Handte", "text": "I can hang in the chat, but I'm flying blind. shrug
", "time": "2023-07-28T00:31:30Z"}, {"author": "Martin Thomson", "text": "@Watson Ladd the basic idea is that there are two blocking points. 1. the client blocks compression for any request that is not readable to the current origin. 2. the server has a heuristic (the CORS you saw) that attempts to infer when the client might block access to compression, because if it compresses when it shouldn't, stuff leaks
", "time": "2023-07-28T00:31:31Z"}, {"author": "Martin Thomson", "text": "@Alan Frindell @Felix Handte yeah, I'm sure it would be hard...
", "time": "2023-07-28T00:32:08Z"}, {"author": "Lucas Pardue", "text": "I like Swedish brotli
", "time": "2023-07-28T00:38:22Z"}, {"author": "Jonathan Hoyland", "text": "Tepid even
", "time": "2023-07-28T00:41:53Z"}, {"author": "Lucas Pardue", "text": "Didn't GW Bush say something like, fool me twice, won't ve fooled again?
", "time": "2023-07-28T00:42:43Z"}, {"author": "Martin Thomson", "text": "That's exactly the sort of tepid response I'm concerned about. Convince me that this is at least worth a solid swing.
", "time": "2023-07-28T00:44:18Z"}, {"author": "Martin Thomson", "text": "I'm happy to be in the rough on this also, but I didn't hear many people jumping up to disagree with me.
", "time": "2023-07-28T00:45:06Z"}, {"author": "Martin Thomson", "text": "@Patrick Meenan is this something you would be able to use in place of pattern matching? Oh, nevermind, you want this to work for previously unseen resources.
I wouldn't mind this being an Experimental draft though I think what Mark is seeking for is having implementations and making sure it works, rather than just publishing an RFC - so interest from implementations on both sides is necessary.
", "time": "2023-07-28T00:46:54Z"}, {"author": "Martin Thomson", "text": "I'd want someone from a CMS to declare interest in the last one ...and someone from a different CDN
", "time": "2023-07-28T00:53:02Z"}, {"author": "Martin Thomson", "text": "\"interesting\" doesn't cut it
", "time": "2023-07-28T00:53:16Z"}, {"author": "Lucas Pardue", "text": "Fair
", "time": "2023-07-28T00:53:57Z"}, {"author": "Martin Thomson", "text": "We tend to push back on people who come to the IETF with \"someone told me they want my new idea\"
", "time": "2023-07-28T00:54:33Z"}, {"author": "Kazuho Oku", "text": "I cannot speak for my employer, but I appreciate Mark trying to build pressure from the customers of CDN, because it's really about what their customers want as a feature.
", "time": "2023-07-28T00:55:33Z"}]