[12:59:24] Sam joins the room
[13:01:39] tfpauly@xmpp.jp joins the room
[13:02:19] blassey joins the room
[13:03:39] 一穂 奥 joins the room
[13:03:46] afrind joins the room
[13:04:43] Piers joins the room
[13:07:40] ioggstream joins the room
[13:08:41] lucasp leaves the room
[13:08:45] James Gruessing joins the room
[13:09:58] francesca joins the room
[13:10:12] lucasp joins the room
[13:10:47] mt joins the room
[13:10:53] <mt> Ooo, I found a client that works!
[13:11:34] Matrix Traveler (bot) joins the room
[13:11:49] <mt> Couldn't work out how to join the room though.
[13:13:44] <mt> QUIC depends on you finishing.
[13:17:18] <ioggstream> lucasp: r-u-there?
[13:17:34] <mt> Oh, good, someone else sent a message and I received it.
[13:17:48] <tfpauly@xmpp.jp> Amazing!
[13:18:12] <ioggstream> mt: ICMP echo reply
[13:19:20] mikebishop joins the room
[13:19:27] <lucasp> webex killed my PC
[13:19:36] <mt> Durable?
[13:19:53] <mt> don't run the client.  webex works fine in Firefox.
[13:22:41] <mt> y u no pseudo-header?
[13:22:57] ekr@jabber.org joins the room
[13:27:14] <Sam> doc says what keys to use is out of scope?!?!?  Seems like key choice - partiularly alg choice - is part of downgrade protection.  why is it out of scope?
[13:30:49] <mt> Don't you also have to sign over the keyId parameter also?
[13:33:12] <Sam> that doesn't stop downgrades, though, right?
[13:33:17] <mt> Is julian talking about "Signature: sig1=(*request-target content-type); signature=:....:, keyId=blah; created=123125
[13:33:38] <mt> Because that seems totally cromulent, if you are able to completely ignore ekr's point.
[13:33:52] afrind leaves the room
[13:35:32] <mt> https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#section-4.1.7-2.2 says that your tokens are invalid.
[13:35:59] ekr@jabber.org leaves the room
[13:37:09] <ioggstream> mt: iiuc the ":" is excluded because it's the way to reference tokens.
[13:37:59] <ioggstream> so "signature:sig1" is not a token if that's what you're pointing out
[13:38:27] <mt> Yes, that's the bit that I was referring to
[13:38:47] <mt> This is also why pseudo-header fields aren't going to work as well.
[13:39:50] <ioggstream> mt: http/2 pseudo-headers? I think extensions should base themself on SEMANTICS, so probably pseudo-headers shouldn't be conveyed there
[13:40:07] <ioggstream> mt: imho/iiuc
[13:41:05] <mt> This is a reasonable point, but the point of using pseudo-header fields for something like this is that we have very clear mappings from the semantics to the representations that use pseudo-header fields.  Having different mappings to different representations creates a difference between in-protocol usage and in-signature usage that could lead to vulnerabilities.
[13:42:19] <ioggstream> This sub-referencing header is generally problematic imho, and could be leveraged to push the parser to parse a given header in a certain way which is in control of the client (which imho is something I'd avoid)
[13:43:32] <ioggstream> (true the other way around for server :P )
[13:43:44] <mt> "Only See What Is Signed"
[13:45:01] <mt> ioggstream: That is a specific example of the class of problem that ekr was talking about.
[13:45:35] <ioggstream> mt: sure.
[13:45:59] <mt> The problem here is that these messages will be consumed and processed in certain ways by intermediaries who will be ignorant of the signatures.  The messages will be signed by entities that don't have visibility into what the ultimate message is and how it is handled.  Does anyone remember how Apple had three XML parsers?
[13:46:18] <ioggstream> mt: +1
[13:46:51] Jeffrey Yasskin joins the room
[13:46:56] mstojens joins the room
[13:48:22] <ioggstream> WRT expiration I think we should ensure the spec provides both sender and recipient to be in charge of what they sign
[13:49:42] <ioggstream> WRT Considerations for new Fields: Can Signature be a Trailer (eg. Signature Field) ?
[13:50:11] <mt> Sam: there is an algorithm field, but I imagine that you might have some idea about an algorithm built into a key that you know about already.
[13:50:59] <Jeffrey Yasskin> Re Sam: I hope this draft drops the algorithm field, and says that profiling specs define how the keyId identifies a key, and then that the key determines the algorithm.
[13:51:26] <mt> Jeffrey Yasskin: That is a reasonable approach.
[13:51:42] mnot joins the room
[13:51:58] <Jeffrey Yasskin> mt: Ah, interesting. How's it break?
[13:52:10] <Jeffrey Yasskin> Oh, sorry, I inserted a "not".
[13:52:16] <mnot> Lucas - ready to try again?
[13:52:18] <ioggstream> Jeffrey Yasskin: mt: ok, but then it only works with certs or PKI
[13:52:41] <lucasp> @mnot yes on this backup laptop
[13:52:44] <ioggstream> (which is fine to me)
[13:52:56] <mt> If you have expectation about keys - you need that to process a signature anyway - then it is reasonable to have a 1:1 mapping from a key to an algorithm.
[13:52:57] <Jeffrey Yasskin> ioggstream: It at least also works with raw public keys as the keyid.
[13:53:23] <mt> I certainly wouldn't want to see RSA-PKCS1v1.5 and RSA-PSS signatures for the same RSA key.
[13:53:53] <ioggstream> Jeffrey Yasskin: sure
[13:53:58] <Sam> do you want comments on this doc in GH? if so, maybe put the link for the repo both here and in the draft tiself?
[13:54:07] <Sam> this = signatures
[13:54:58] <ioggstream> https://github.com/httpwg/http-extensions/issues/1176 <-
[13:55:28] afrind joins the room
[13:58:16] <mt> remind me why initial prioritization needs to use frames on the control stream?
[13:58:41] <mt> If the control stream was only used for reprioritization, ...
[14:03:00] <mnot> Brad says his laptop has frozen - can someone please help with minutes?
[14:05:56] liamdennehy joins the room
[14:07:27] <afrind> For non-incremental, does the doc describe how to order streams?  Lowest stream ID first doesn't work because request and push streams have different ID spaces
[14:08:07] <lucasp> yes afrind, that along the lines of my last comment on the issue
[14:08:28] <lucasp> I think you can't look at stream ID alone but consider "request generation order"
[14:09:52] ekr@jabber.org joins the room
[14:09:55] <afrind> if prioritization is happening in the transport, it may not be aware of push IDs
[14:10:18] <mt> prioritization has to be driven by the application layer at some point
[14:10:59] <mt> stream N, all pushes associated with N in push ID order, stream N+4, all pushes....
[14:11:52] <一穂 奥> +1
[14:12:58] <afrind> It just complicates transport API.  Letting the non-incremental bucket go by stream ID was very simple.
[14:13:33] <mt> Yeah, I know.  It's something that I'm glad I don't have to deal with (I'm putting that off)
[14:13:45] <lucasp> I agree with afrind there could be challenges based on implementation. But I don't this can be solved by trying to be clever in the application layer
[14:14:07] <lucasp> I'd rather just not implement push TBH
[14:14:18] <mnot> +1 lucas
[14:15:34] <afrind> lol
[14:16:31] <mt> intermediaries can do anything you don't prevent them from doing
[14:16:38] <mt> so yes, intermediaries will rewrite Digest
[14:16:51] <mt> saying MUST NOT won't do you much good
[14:16:52] <mnot> intermediaries gonna intermediate
[14:17:11] <mt> read my mind
[14:17:49] <lucasp> interfere-diaries, amitire?
[14:18:28] <mt> Option 1: Avoid Intermediation (https://martinthomson.github.io/tmi/draft-thomson-tmi.html)
[14:21:54] <ioggstream> mt: so SHOULD NOT or nothing ?
[14:24:29] <mt> so I would merely point out that intermediaries that modify digests risk breaking things that depend on those digests (like signatures)
[14:24:36] <mt> no normative language at all
[14:24:55] <ioggstream> mt: ok, we already stated that lucasp
[14:25:17] <lucasp> sgtm
[14:27:56] <mt> offov yawls plaits
[14:28:00] liamdennehy joins the room
[14:29:26] <Sam> sounds like a chicken and egg problem: Mark doesn't want things in the spec util they ship, and EKR doesn't want to ship things unless they're in the spec.
[14:29:40] <mnot> not what I said sam
[14:30:04] <ekr@jabber.org> We're happy to preliminarily ship them once they are in a WG I-D.
[14:30:13] liamdennehy leaves the room: Disconnected: BOSH client silent for over 60 seconds
[14:30:17] <Sam> ah, good.
[14:30:29] <ekr@jabber.org> We're not happy to ship them when they are in an individual I-D, which is why they are being held behind a flag
[14:30:36] <Sam> great
[14:30:53] <Sam> tnx for the clarifications
[14:31:42] <Sam> mkwst++
[14:32:52] afrind leaves the room
[14:33:00] liamdennehy leaves the room
[14:33:17] <mnot> Many thanks to Brad for scribing!
[14:33:34] mikebishop leaves the room
[14:33:52] mstojens leaves the room
[14:35:40] mnot leaves the room: Disconnected: closed
[14:39:31] tfpauly@xmpp.jp leaves the room
[14:39:31] James Gruessing leaves the room
[14:40:00] ekr@jabber.org leaves the room
[14:41:50] <ioggstream> mt: the issues you filed on Digest... Obsoleting all non-crypto algorithms but crc32c is a good fix for you  https://github.com/httpwg/http-extensions/issues?q=is%3Aopen+label%3Adigest-headers+author%3Amartinthomson
[14:42:21] <ioggstream> ?
[14:42:50] <ioggstream> Once we fix them, I think we're almost ready for a WGLC
[14:51:36] Jeffrey Yasskin leaves the room
[14:56:19] francesca joins the room
[14:57:17] francesca leaves the room
[15:06:42] <Sam> nice job on the minutes today.  Went back to see how my comments were minuted, and they look good!
[15:07:18] <Sam> thank you, scribe!
[15:11:10] <blassey> collective effort
[15:11:38] <Sam> thank you scribes!
[15:31:17] afrind joins the room
[15:31:36] Piers leaves the room
[15:42:18] afrind leaves the room
[16:17:31] francesca leaves the room
[16:38:45] ioggstream leaves the room
[17:13:49] lucasp leaves the room
[19:18:20] zash joins the room
[19:18:58] Zash joins the room
[19:19:39] zash leaves the room
[19:29:53] undefined joins the room
[20:05:39] Zash leaves the room
[21:04:38] lucasp joins the room
[21:14:20] lucasp leaves the room
[22:17:57] 一穂 奥 leaves the room
[23:34:04] 一穂 奥 joins the room
[23:34:05] 一穂 奥 leaves the room
[23:34:08] 一穂 奥 joins the room
[23:34:08] 一穂 奥 leaves the room