[{"author": "Yoav Nir", "text": "I think with a hybrid meeting, not even a proxy proposal would pack the room.<br/>", "time": "2022-03-23T09:00:02Z"}, {"author": "Yoav Nir", "text": "Can someone with a proper Jabber client fix the topic?<br/>", "time": "2022-03-23T09:00:14Z"}, {"author": "Martin Thomson", "text": "did we sort out the ordering?<br/>", "time": "2022-03-23T09:02:46Z"}, {"author": "Thom Wiggers", "text": "Slides died<br/>", "time": "2022-03-23T09:03:26Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "MT: ordering of ... handshake messages?&nbsp;&nbsp;Or documents?<br/>", "time": "2022-03-23T09:03:42Z"}, {"author": "Martin Thomson", "text": "the hybrid key exchange presentation was marked specially in the agenda<br/>", "time": "2022-03-23T09:03:54Z"}, {"author": "dkg", "text": "slides are gone<br/>", "time": "2022-03-23T09:03:55Z"}, {"author": "Martin Thomson", "text": "it's the \"document\" icon<br/>", "time": "2022-03-23T09:05:17Z"}, {"author": "Martin Thomson", "text": "do you need the length AND the fragmentation pieces?<br/>", "time": "2022-03-23T09:11:04Z"}, {"author": "Martin Thomson", "text": "SGTM<br/>", "time": "2022-03-23T09:13:30Z"}, {"author": "Martin Thomson", "text": "these seem like clear examples of stuff that can be added as an extension<br/>", "time": "2022-03-23T09:14:19Z"}, {"author": "jhoyla", "text": "I don't follow the logic of why you can drop the Finished? Because the record layer performs the same function?<br/>", "time": "2022-03-23T09:16:29Z"}, {"author": "Martin Thomson", "text": "so would you take the on-the-wire transcript instead?<br/>", "time": "2022-03-23T09:16:41Z"}, {"author": "Deb Cooley", "text": "Hannes, you are very tiny....<br/>", "time": "2022-03-23T09:17:11Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "jhoyla: I think that's the idea, yeah, that the AEAD tag performs<br/>key-confirmation for the final keys...but huh, what about the client's<br/>final flight.<br/>", "time": "2022-03-23T09:17:21Z"}, {"author": "Martin Thomson", "text": "the finished thing is probably the thingthat makes me most nervous<br/>", "time": "2022-03-23T09:17:43Z"}, {"author": "Martin Thomson", "text": "what if one endpoint never sends application data?<br/>", "time": "2022-03-23T09:17:59Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Indeed, there are many reasons to be nervous about the finished thing<br/>", "time": "2022-03-23T09:18:19Z"}, {"author": "jhoyla", "text": "For example if you're in EAP-TLS<br/>", "time": "2022-03-23T09:18:19Z"}, {"author": "Deb Cooley", "text": "@Martin:&nbsp;&nbsp;Is there actually a channel at all in that case?<br/>", "time": "2022-03-23T09:18:30Z"}, {"author": "Richard Barnes", "text": "Hannes is also very yellow<br/>", "time": "2022-03-23T09:18:34Z"}, {"author": "Deb Cooley", "text": "@rlb&nbsp;&nbsp;LOL<br/>", "time": "2022-03-23T09:18:49Z"}, {"author": "Sean Turner", "text": "safety dance!<br/>", "time": "2022-03-23T09:18:53Z"}, {"author": "Martin Thomson", "text": "deb: it might not be symmetric, so one side might want to send, but they haven't received Finished to confirm the keys of its peer.<br/>", "time": "2022-03-23T09:19:03Z"}, {"author": "Benjamin Schwartz", "text": "To be clear, the draft currently supports reducing the Random and Finished size to a custom value, which can be zero.<br/>", "time": "2022-03-23T09:19:07Z"}, {"author": "Martin Thomson", "text": "as stated, this needs careful analysis<br/>", "time": "2022-03-23T09:19:13Z"}, {"author": "Robin Wilton", "text": "Hannes is closer to red shift than blue shift...<br/>", "time": "2022-03-23T09:19:19Z"}, {"author": "jhoyla", "text": "@Thom, how much work do you think it would be to include the record layer into the Tamarin model? <br/>", "time": "2022-03-23T09:19:44Z"}, {"author": "Martin Thomson", "text": "I think that you can make an information theoretic argument for use of the CTLS transcript on the basis that any negotiation is either embodied in the profile (via profile ID) or in the transcript<br/>", "time": "2022-03-23T09:20:17Z"}, {"author": "Richard Barnes", "text": "To be clear, my clever ideas only only turn out to be actually clever about 60% of the time<br/>", "time": "2022-03-23T09:20:38Z"}, {"author": "Richard Barnes", "text": "that may be an overestimate<br/>", "time": "2022-03-23T09:20:50Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "\"authenticate the bits as they were on the wire\" does have something<br/>going for it<br/>", "time": "2022-03-23T09:20:52Z"}, {"author": "Martin Thomson", "text": "kaduk, precisely<br/>", "time": "2022-03-23T09:21:04Z"}, {"author": "Benjamin Schwartz", "text": "I wonder if we need to worry about profile disagreements though<br/>", "time": "2022-03-23T09:21:28Z"}, {"author": "Deb Cooley", "text": "@rlb more often than some<br/>", "time": "2022-03-23T09:21:32Z"}, {"author": "Benjamin Schwartz", "text": "Consider an adversary who can swap out the profile contents...<br/>", "time": "2022-03-23T09:21:41Z"}, {"author": "Thom Wiggers", "text": "@jhoyla: it\u2019s already somewhat&nbsp;&nbsp;included in the TLS13 model but doesn\u2019t cover the aead properties<br/>", "time": "2022-03-23T09:21:46Z"}, {"author": "Martin Thomson", "text": "ben schwartz: yes, that bothers me a little, which we might do by hashing a profile, for example<br/>", "time": "2022-03-23T09:21:56Z"}, {"author": "Benjamin Schwartz", "text": "Martin: Yep.&nbsp;&nbsp;But then we need a canonical representation of the profile...<br/>", "time": "2022-03-23T09:22:18Z"}, {"author": "jhoyla", "text": "@kaduk From a symbolic proof perspective I don't think that the bits on the wire changes actually make a difference to the proof. <br/>", "time": "2022-03-23T09:22:19Z"}, {"author": "Martin Thomson", "text": "though as JSON, it's not necessarily in a canonical form<br/>", "time": "2022-03-23T09:22:19Z"}, {"author": "Martin Thomson", "text": "haha :)<br/>", "time": "2022-03-23T09:22:28Z"}, {"author": "Thom Wiggers", "text": "If you want to model cTLS you might want to be able turn off/on all the options especially if you get rid of the reconstruction<br/>", "time": "2022-03-23T09:22:43Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "jhoyla: I also think so...which is why the \"something\" that it has<br/>going for it is rather under-specified :)<br/>", "time": "2022-03-23T09:23:00Z"}, {"author": "jhoyla", "text": "@Thom I think we could add the AEAD properties pretty easily, because the functions are already defined in other models<br/>", "time": "2022-03-23T09:23:02Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "MT: but JCS!<br/>", "time": "2022-03-23T09:23:11Z"}, {"author": "Robin Wilton", "text": "@Richard The phrase \"I've had this *really clever* idea that will save us 4 bytes of storage\" has been striking fear into maintainers' hearts since the invention of the computer.<br/>", "time": "2022-03-23T09:23:20Z"}, {"author": "Christopher Patton", "text": "\"PCS\"?<br/>", "time": "2022-03-23T09:23:21Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "post-compromise security<br/>", "time": "2022-03-23T09:23:29Z"}, {"author": "Thom Wiggers", "text": "jhoyla: agreed<br/>", "time": "2022-03-23T09:23:31Z"}, {"author": "Sean Turner", "text": "post compromise<br/>", "time": "2022-03-23T09:23:31Z"}, {"author": "Christopher Patton", "text": "thanks<br/>", "time": "2022-03-23T09:23:41Z"}, {"author": "Martin Thomson", "text": "kaduk: nice try<br/>", "time": "2022-03-23T09:23:54Z"}, {"author": "Martin Thomson", "text": "please, we don't need to do renegotiation in TLS 1.3, or if we do, someone can write an extension<br/>", "time": "2022-03-23T09:24:24Z"}, {"author": "Martin Thomson", "text": "these granular alerts are a royal pain; definitely reduce it to one<br/>", "time": "2022-03-23T09:25:14Z"}, {"author": "Thom Wiggers", "text": "jhoyla: implicit auth does basically mean that until a peer sends something you don\u2019t have confirmation on their choices for hello parameters (which cTLS presumably just hard codes)<br/>", "time": "2022-03-23T09:25:25Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "certificate_rejected<br/>", "time": "2022-03-23T09:25:29Z"}, {"author": "Martin Thomson", "text": "thom: not all choices will be hard coded<br/>", "time": "2022-03-23T09:25:43Z"}, {"author": "jhoyla", "text": "Is having exactly one PSK error significantly different from having zero PSK errors?<br/>", "time": "2022-03-23T09:25:45Z"}, {"author": "Christopher Patton", "text": "I like the proposal as well<br/>", "time": "2022-03-23T09:26:28Z"}, {"author": "Christopher Patton", "text": "KISS<br/>", "time": "2022-03-23T09:26:36Z"}, {"author": "Joseph Salowey", "text": "less is more<br/>", "time": "2022-03-23T09:26:45Z"}, {"author": "Sean Turner", "text": "you can give the general \"error\" or provide info that you know it's about a PSK<br/>", "time": "2022-03-23T09:26:51Z"}, {"author": "Rich Salz", "text": "\"wrong username\"/\"wrong password\" vs \"login failed\"<br/>", "time": "2022-03-23T09:27:03Z"}, {"author": "Rich Salz", "text": "i have not found detailed alerts very usefl for debugging.&nbsp;&nbsp;most commonly, it gives Hubert Khario something to complain about ;)<br/>", "time": "2022-03-23T09:27:47Z"}, {"author": "Martin Thomson", "text": "HRR contains the negotiated cipher suite, right?&nbsp;&nbsp;in which case, we are good<br/>", "time": "2022-03-23T09:28:33Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "I agree that it should be the negotiated hash used for message_hash<br/>reinjection.&nbsp;&nbsp;No comment on what the current text says.<br/>", "time": "2022-03-23T09:28:35Z"}, {"author": "Martin Thomson", "text": "this is good, because that is what people implement in practice<br/>", "time": "2022-03-23T09:28:58Z"}, {"author": "Martin Thomson", "text": "though it's not very well tested, I'm sure<br/>", "time": "2022-03-23T09:29:12Z"}, {"author": "jhoyla", "text": "Given that there isn't downgrade protection on CH2 is there anything bad that can happen if you use the negotiated hash?<br/>", "time": "2022-03-23T09:29:15Z"}, {"author": "jhoyla", "text": "I don't think so, but it makes me a bit nervous.<br/>", "time": "2022-03-23T09:29:27Z"}, {"author": "jhoyla", "text": "(Or rather, there isn't downgrade protection of CH2 until the server Finished)<br/>", "time": "2022-03-23T09:30:01Z"}, {"author": "Martin Thomson", "text": "davidben isn't here, so maybe we won't make progress<br/>", "time": "2022-03-23T09:31:02Z"}, {"author": "sftcd-x-x", "text": "maybe not a minimum thing, but entirely ditching HRR seems like it should be attractive :-)<br/>", "time": "2022-03-23T09:31:03Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "I don't see davidben in the participants list :(<br/>", "time": "2022-03-23T09:31:05Z"}, {"author": "Martin Thomson", "text": "I think that his approach is dangerous, but he is right that it isn't absolute<br/>", "time": "2022-03-23T09:31:23Z"}, {"author": "Sean Turner", "text": "that's a good way forward ekr<br/>", "time": "2022-03-23T09:31:44Z"}, {"author": "Martin Thomson", "text": "wfm<br/>", "time": "2022-03-23T09:31:50Z"}, {"author": "Sean Turner", "text": "on 1214 - that's fine it's why there's 8447bis<br/>", "time": "2022-03-23T09:32:47Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "I think 1206 was passing an IESG ballot comment on DTLS 1.3 over to<br/>8446bis as \"more appropriately handled\" here, but have no objection to<br/>closing with no change<br/>", "time": "2022-03-23T09:33:09Z"}, {"author": "Martin Thomson", "text": "multiple identities is an application issue; we just have to say that it can happen<br/>", "time": "2022-03-23T09:33:24Z"}, {"author": "Richard Barnes", "text": "-ter<br/>", "time": "2022-03-23T09:34:18Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "8446bisbis rather than 8446ter?<br/>", "time": "2022-03-23T09:34:21Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "*high-five* Barnes :)<br/>", "time": "2022-03-23T09:34:30Z"}, {"author": "Richard Barnes", "text": "\ud83d\ude4c\ud83c\udffb<br/>", "time": "2022-03-23T09:34:44Z"}, {"author": "jhoyla", "text": "Could SNIP allow a client to abandon a TLS 1.3 connection attempt before it completes and move to a QUIC option?<br/>", "time": "2022-03-23T09:36:42Z"}, {"author": "Sean Turner", "text": "Unless people start beating down the door - we are going to park it<br/>", "time": "2022-03-23T09:36:46Z"}, {"author": "Benjamin Schwartz", "text": "It might be straightforward to implement in the context of an HTTP server that has built-in support for HTTP/3.<br/>", "time": "2022-03-23T09:36:59Z"}, {"author": "Martin Thomson", "text": "jhoyla: basically, yes<br/>", "time": "2022-03-23T09:37:06Z"}, {"author": "Christopher Wood", "text": "Douglas is not here.<br/>", "time": "2022-03-23T09:37:41Z"}, {"author": "Eric Rescorla", "text": "It is very confusing to me that this is not the same as \"Hybrid Public Key Exchange\"<br/>", "time": "2022-03-23T09:37:51Z"}, {"author": "Martin Thomson", "text": "the naming here is very unfortunate<br/>", "time": "2022-03-23T09:38:05Z"}, {"author": "jhoyla", "text": "@MT Cool, it would mess with some of my experiments, but I like the idea. <br/>", "time": "2022-03-23T09:38:18Z"}, {"author": "Christopher Patton", "text": "HPKE = hybrid PKE<br/>", "time": "2022-03-23T09:38:27Z"}, {"author": "Florence D", "text": "There's been similar discussion about naming on the LAMPS mailing list<br/>", "time": "2022-03-23T09:38:31Z"}, {"author": "Sean Turner", "text": "haha<br/>", "time": "2022-03-23T09:38:34Z"}, {"author": "Dennis Jackson", "text": ":-P<br/>", "time": "2022-03-23T09:38:37Z"}, {"author": "Christopher Patton", "text": "lol<br/>", "time": "2022-03-23T09:38:37Z"}, {"author": "Thom Wiggers", "text": "Hyper pke<br/>", "time": "2022-03-23T09:38:50Z"}, {"author": "Deb Cooley", "text": "just ban the word 'hybrid' altogether<br/>", "time": "2022-03-23T09:38:51Z"}, {"author": "sftcd-x-x", "text": "+1 for spending a year or so talking about terminology before doing anything substantive on PQC in protocols :-)<br/>", "time": "2022-03-23T09:38:54Z"}, {"author": "Eric Orth", "text": "They're still similar-sounding enough that it confused me in the same way at this early hour.<br/>", "time": "2022-03-23T09:38:55Z"}, {"author": "Richard Barnes", "text": "+1 deb<br/>", "time": "2022-03-23T09:38:56Z"}, {"author": "Eric Rescorla", "text": "Hilarious Public Key Exchange?<br/>", "time": "2022-03-23T09:39:05Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "genetic hybridization only?<br/>", "time": "2022-03-23T09:39:05Z"}, {"author": "Panos Kampanakis", "text": "PQ-hybrid is probably clearer<br/>", "time": "2022-03-23T09:39:13Z"}, {"author": "Deb Cooley", "text": "no-GMO<br/>", "time": "2022-03-23T09:39:19Z"}, {"author": "Sean Turner", "text": "@stfcd - aren't you missing another X?<br/>", "time": "2022-03-23T09:39:21Z"}, {"author": "Britta Hale", "text": "Ekr is correct, that is different.<br/>", "time": "2022-03-23T09:39:23Z"}, {"author": "Vincent Cheval", "text": "Problem with my mic apparently<br/>", "time": "2022-03-23T09:39:24Z"}, {"author": "Martin Thomson", "text": "homomorphic private key exposure<br/>", "time": "2022-03-23T09:39:26Z"}, {"author": "Martin Thomson", "text": "homomorphic private key exfiltration<br/>", "time": "2022-03-23T09:39:44Z"}, {"author": "Vincent Cheval", "text": "Mic is not working<br/>", "time": "2022-03-23T09:39:48Z"}, {"author": "sftcd-x-x", "text": "@turner: I can add another -x later<br/>", "time": "2022-03-23T09:39:50Z"}, {"author": "Mike Ounsworth", "text": "Re naming of \"Hybrid key exchange\": the lamps thread is: <a href=\"https://mailarchive.ietf.org/arch/msg/spasm/P9kKu-3ToUvYwidY8fUGoiYu0Dg/\" rel=\"nofollow\">https://mailarchive.ietf.org/arch/msg/spasm/P9kKu-3ToUvYwidY8fUGoiYu0Dg/</a><br/>", "time": "2022-03-23T09:40:02Z"}, {"author": "Richard Barnes", "text": "@sftcd-x-x please save @sftcd-xxx for after the meeting<br/>", "time": "2022-03-23T09:40:14Z"}, {"author": "Mike Ounsworth", "text": "I personally prefer \"multi-key KEM\" or \"multi-algorithm KEM\", of which \"composite\" is a specific multi-key scheme.<br/>", "time": "2022-03-23T09:40:27Z"}, {"author": "Martin Thomson", "text": "Joe, try reloading<br/>", "time": "2022-03-23T09:40:30Z"}, {"author": "Martin Thomson", "text": "wheee!<br/>", "time": "2022-03-23T09:40:50Z"}, {"author": "Vincent Cheval", "text": "I have a permission problem<br/>", "time": "2022-03-23T09:40:56Z"}, {"author": "Eric Rescorla", "text": "Which browser are you in?<br/>", "time": "2022-03-23T09:41:15Z"}, {"author": "Deb Cooley", "text": "@ekr, LOL<br/>", "time": "2022-03-23T09:41:29Z"}, {"author": "Martin Thomson", "text": "you don't need to restart<br/>", "time": "2022-03-23T09:41:30Z"}, {"author": "Martin Thomson", "text": "but you need to know how to navigate the UI<br/>", "time": "2022-03-23T09:41:37Z"}, {"author": "sofiaceli", "text": "Unfortunately, the \u2018hybrid\u2019 name is part of the NIST post-quantum competition and is referred now academically also as so: <a href=\"https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs\" rel=\"nofollow\">https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs</a><br/>", "time": "2022-03-23T09:41:43Z"}, {"author": "Eric Rescorla", "text": "@deb: well, I was going to walk him through the UI<br/>", "time": "2022-03-23T09:41:43Z"}, {"author": "Martin Thomson", "text": "and it isn't exactly obvious<br/>", "time": "2022-03-23T09:41:43Z"}, {"author": "Deb Cooley", "text": "Firefox for the win<br/>", "time": "2022-03-23T09:41:43Z"}, {"author": "Mike Ounsworth", "text": "There was some discussion on LAMPS that maybe we need a draft to standardize language for talking about multi-key / hybrid / dual / composite PQ stuffs<br/>", "time": "2022-03-23T09:41:51Z"}, {"author": "Rich Salz", "text": "yeah, clap clap<br/>", "time": "2022-03-23T09:42:29Z"}, {"author": "jhoyla", "text": "Can we increase Vincent's gain?<br/>", "time": "2022-03-23T09:42:31Z"}, {"author": "Florence D", "text": "@mike I think it's good to break down what's 'composite' further than the scheme.&nbsp;&nbsp;Because you could have a 'composite' signature using 'non-composite' keys for example.<br/>", "time": "2022-03-23T09:42:38Z"}, {"author": "Eric Rescorla", "text": "In any browser, however, if you reload the page (?) or re-ask for media (?) it should re-prompt you for permissions<br/>", "time": "2022-03-23T09:42:39Z"}, {"author": "Andrew Campling", "text": "Vincent is a little quiet in the room<br/>", "time": "2022-03-23T09:42:46Z"}, {"author": "Florence D", "text": "Then I suppose there's also the \"dual signature\" language which might be clearer<br/>", "time": "2022-03-23T09:43:00Z"}, {"author": "sofiaceli", "text": "Yes! @Mike that will be nice, as confusingly enough it is \u2018hybrid\u2019 for key exchange, and \u2018dual\u2019 for signatures, according to NIST<br/>", "time": "2022-03-23T09:43:02Z"}, {"author": "Eric Rescorla", "text": "Are composite keys when they are non-prime?<br/>", "time": "2022-03-23T09:43:24Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "Vincent is still kind of quiet.<br/>", "time": "2022-03-23T09:43:43Z"}, {"author": "Andrew Campling", "text": "The in-room sound is still pretty quiet<br/>", "time": "2022-03-23T09:43:59Z"}, {"author": "jhoyla", "text": "Yeah, I can't hear at all<br/>", "time": "2022-03-23T09:44:04Z"}, {"author": "Eric Rescorla", "text": "I made him loader by jacking up my local gain<br/>", "time": "2022-03-23T09:44:11Z"}, {"author": "Rich Salz", "text": "ditto<br/>", "time": "2022-03-23T09:44:22Z"}, {"author": "Florence D", "text": "@ekr - I'm ashamed I've never thought of that joke before<br/>", "time": "2022-03-23T09:44:22Z"}, {"author": "Eric Rescorla", "text": "loader, actually<br/>", "time": "2022-03-23T09:44:35Z"}, {"author": "jhoyla", "text": "We can all go and cuddle the speaker I guess :P <br/>", "time": "2022-03-23T09:44:44Z"}, {"author": "Mike Ounsworth", "text": "@ekr /facepalm<br/>", "time": "2022-03-23T09:44:49Z"}, {"author": "Thom Wiggers", "text": "I don\u2019t think I can pick up the room speakers and put them in front of me<br/>", "time": "2022-03-23T09:44:52Z"}, {"author": "jhoyla", "text": "That is not the list of properties in the document ...<br/>", "time": "2022-03-23T09:45:50Z"}, {"author": "Sean Turner", "text": "yeah it would be good to have two for all<br/>", "time": "2022-03-23T09:46:52Z"}, {"author": "Thom Wiggers", "text": "Should be trivial to extend the tamarin model for client identity privacy<br/>", "time": "2022-03-23T09:48:29Z"}, {"author": "Sean Turner", "text": "@Thom have they automated the button pressing yet? :)<br/>", "time": "2022-03-23T09:48:55Z"}, {"author": "Eric Rescorla", "text": "\"Should be trivial\" is usually the start of a paper called \"breaking and repairing....\"<br/>", "time": "2022-03-23T09:49:11Z"}, {"author": "jhoyla", "text": "@SPT Thom managed to automate pretty much all the proofs, paper forthcoming! <br/>", "time": "2022-03-23T09:49:23Z"}, {"author": "Thom Wiggers", "text": "My KEMTLS model variant has no button pressing o/<br/>", "time": "2022-03-23T09:49:24Z"}, {"author": "Sean Turner", "text": "awesome sauce<br/>", "time": "2022-03-23T09:49:37Z"}, {"author": "kaduk@jabber.org/barnowl", "text": ":celebrate:<br/>", "time": "2022-03-23T09:49:47Z"}, {"author": "Sean Turner", "text": ":profit:<br/>", "time": "2022-03-23T09:49:56Z"}, {"author": "Rich Salz", "text": ":tenure:<br/>", "time": "2022-03-23T09:50:05Z"}, {"author": "jhoyla", "text": ":joy:<br/>", "time": "2022-03-23T09:50:30Z"}, {"author": "Richard Barnes", "text": "is the \"hpke\" on the slide referring to the post-quantum stuff?<br/>", "time": "2022-03-23T09:50:47Z"}, {"author": "Thom Wiggers", "text": "Rich: I\u2019ll tell Peter Schwabe to give me my PhD then<br/>", "time": "2022-03-23T09:50:48Z"}, {"author": "Martin Thomson", "text": "looking at these diagrams I am reminded of just how deep this gets<br/>", "time": "2022-03-23T09:51:08Z"}, {"author": "Christopher Wood", "text": "ECH is complicated.<br/>", "time": "2022-03-23T09:51:16Z"}, {"author": "jhoyla", "text": "*cough* channel bindings *cough*<br/>", "time": "2022-03-23T09:51:17Z"}, {"author": "Sean Turner", "text": "I like that the font keeps getting smaller and smaller and smaller ;)<br/>", "time": "2022-03-23T09:51:35Z"}, {"author": "sftcd-x-x", "text": "ECH isn't so bad, ECH+HRR is an utter PITA<br/>", "time": "2022-03-23T09:51:38Z"}, {"author": "Martin Thomson", "text": "this has got to be hugely intimidating<br/>", "time": "2022-03-23T09:51:49Z"}, {"author": "jhoyla", "text": "(I guess that format is much scarier for the in person people ;P)<br/>", "time": "2022-03-23T09:51:53Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "What was sftcd-x-x saying earlier?&nbsp;&nbsp;Get rid of HRR?<br/>", "time": "2022-03-23T09:51:53Z"}, {"author": "David Schinazi", "text": "Can confirm this is hugely intimidating for enthusiasts<br/>", "time": "2022-03-23T09:52:05Z"}, {"author": "Deb Cooley", "text": "I must be old - I can't hear, and I certainly can't read those slides...<br/>", "time": "2022-03-23T09:52:06Z"}, {"author": "Martin Thomson", "text": "deb: not many people can, even if they weren't in ant font<br/>", "time": "2022-03-23T09:52:32Z"}, {"author": "sftcd-x-x", "text": "I loaded the slides locally <a href=\"https://datatracker.ietf.org/meeting/113/materials/slides-113-tls-tls-security-analysis-00\" rel=\"nofollow\">https://datatracker.ietf.org/meeting/113/materials/slides-113-tls-tls-security-analysis-00</a><br/>", "time": "2022-03-23T09:52:45Z"}, {"author": "Deb Cooley", "text": "shew<br/>", "time": "2022-03-23T09:52:50Z"}, {"author": "Christopher Patton", "text": "Implementing ECH is complicated, yes. But it's also a pretty major change to to the protocol. Not sure if it could have been simpler..<br/>", "time": "2022-03-23T09:52:54Z"}, {"author": "Deb Cooley", "text": "LOL...<br/>", "time": "2022-03-23T09:53:06Z"}, {"author": "Eric Rescorla", "text": "It's fine to just have TLS 1.3, b/c ECH doesn't work with TLS 1.2<br/>", "time": "2022-03-23T09:53:09Z"}, {"author": "Benjamin Schwartz", "text": "We could have dropped support for HRR<br/>", "time": "2022-03-23T09:53:11Z"}, {"author": "jhoyla", "text": "48H and 100GB are pretty low limits for a Tamarin proof ;P<br/>", "time": "2022-03-23T09:53:14Z"}, {"author": "Eric Rescorla", "text": "I'll buy some more memory<br/>", "time": "2022-03-23T09:53:26Z"}, {"author": "Rich Salz", "text": "just don't run chrome when doing proofs<br/>", "time": "2022-03-23T09:53:37Z"}, {"author": "Eric Rescorla", "text": "@bemasc: yeah, but I think we're gonna really need it when we do PQ<br/>", "time": "2022-03-23T09:53:48Z"}, {"author": "Martin Thomson", "text": "down took a fair while<br/>", "time": "2022-03-23T09:54:05Z"}, {"author": "Dennis Jackson", "text": "@ekr - Doesn't exclude cross-version attacks<br/>", "time": "2022-03-23T09:54:16Z"}, {"author": "Eric Rescorla", "text": "@Dennis: correct. But maybe there's some way to stylize that<br/>", "time": "2022-03-23T09:54:35Z"}, {"author": "jhoyla", "text": "Tamarin stresses browsers pretty hard actually. You can max out the DOM tree and redrawing a 28MB page for each proof step makes both Chrome and FF choke.<br/>", "time": "2022-03-23T09:54:43Z"}, {"author": "Eric Rescorla", "text": "Like model it as fall back to plaintext or something<br/>", "time": "2022-03-23T09:54:45Z"}, {"author": "sftcd-x-x", "text": "is there also an assumption here that the same ech-config is used for BS1 &amp; BS2? that might not always happen due to DNS caching<br/>", "time": "2022-03-23T09:55:26Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "I can see the headlines now: \"TLS protocol author says TLS 1.2 is equivalent to plaintext\"<br/>", "time": "2022-03-23T09:55:31Z"}, {"author": "jhoyla", "text": "Or as a bunch of oracles to simulate being able to extract info from TLS 1.2<br/>", "time": "2022-03-23T09:55:38Z"}, {"author": "Christopher Wood", "text": "@sftcd yeah, that's correct<br/>", "time": "2022-03-23T09:55:51Z"}, {"author": "Christopher Wood", "text": "(it assumes a consistent configuration across BS1 and BS2)<br/>", "time": "2022-03-23T09:55:59Z"}, {"author": "sftcd-x-x", "text": "you'd hope if the same groups are used it should be fine but be nice if that were considered (ekr said he'd add more RAM:-)<br/>", "time": "2022-03-23T09:56:22Z"}, {"author": "jhoyla", "text": "@kaduk LOL!<br/>", "time": "2022-03-23T09:56:27Z"}, {"author": "Thom Wiggers", "text": "@jhoyla: that requires modeling tls12; seems easier to model it as a \u201cbad\u201d state<br/>", "time": "2022-03-23T09:56:40Z"}, {"author": "Christopher Patton", "text": "yes, thank you for the work!<br/>", "time": "2022-03-23T09:57:06Z"}, {"author": "Dan McArdle", "text": "Very very cool!<br/>", "time": "2022-03-23T09:57:09Z"}, {"author": "Dan McArdle", "text": "Are slides available somewhere?<br/>", "time": "2022-03-23T09:57:14Z"}, {"author": "sftcd-x-x", "text": "<a href=\"https://datatracker.ietf.org/meeting/113/materials/slides-113-tls-tls-security-analysis-00\" rel=\"nofollow\">https://datatracker.ietf.org/meeting/113/materials/slides-113-tls-tls-security-analysis-00</a><br/>", "time": "2022-03-23T09:57:18Z"}, {"author": "Dan McArdle", "text": "Awesome, thanks sftcd-xxx!<br/>", "time": "2022-03-23T09:57:38Z"}, {"author": "jhoyla", "text": "@Thom, I don't think so, I think you could just have a few functions that leak some state, and say that they overapproximate the info you could possibly derive from 1.2<br/>", "time": "2022-03-23T09:57:40Z"}, {"author": "Thom Wiggers", "text": "@ekr: the room here is a bit echoey, could you maybe slow down just the tiniest bit:innocent:<br/>", "time": "2022-03-23T09:58:11Z"}, {"author": "Richard Barnes", "text": "if you don't have 1TB of memory, are you even using a computer?<br/>", "time": "2022-03-23T09:58:30Z"}, {"author": "Thom Wiggers", "text": "Perfect<br/>", "time": "2022-03-23T09:58:33Z"}, {"author": "Eric Rescorla", "text": "Again, fantastic work<br/>", "time": "2022-03-23T09:58:40Z"}, {"author": "Eric Rescorla", "text": "I would just put check marks on some of the places where they have xs<br/>", "time": "2022-03-23T09:58:59Z"}, {"author": "Martin Thomson", "text": "yeah, this is great.&nbsp;&nbsp;and what this says is that x means \"we don't know for sure that this is OK\" as opposed to \"this is broken\"<br/>", "time": "2022-03-23T09:59:04Z"}, {"author": "Paul Wouters", "text": "who is speaking ?<br/>", "time": "2022-03-23T09:59:28Z"}, {"author": "Mike Ounsworth", "text": "Oh the network inspection question again ...<br/>", "time": "2022-03-23T09:59:31Z"}, {"author": "Christopher Wood", "text": "This is out of scope for the analysis.<br/>", "time": "2022-03-23T09:59:40Z"}, {"author": "jhoyla", "text": "I used a little clock icon to indicate that the proof wasn't available yet <br/>", "time": "2022-03-23T09:59:52Z"}, {"author": "sftcd-x-x", "text": "you'd guess if there's a deliberate MITM then all security properties are more or&nbsp;&nbsp;less lost<br/>", "time": "2022-03-23T09:59:52Z"}, {"author": "Rich Salz", "text": "Agreed, he analyzed it, didn't write it.<br/>", "time": "2022-03-23T09:59:57Z"}, {"author": "dkg", "text": "when you add network inspection to the model, then the privacy properties are gone, no?<br/>", "time": "2022-03-23T10:00:10Z"}, {"author": "Andrew Campling", "text": "Arnaud Taddei is speaking<br/>", "time": "2022-03-23T10:00:11Z"}, {"author": "Eric Rescorla", "text": "Indeed.<br/>", "time": "2022-03-23T10:00:23Z"}, {"author": "dkg", "text": "that's the point of network inspection<br/>", "time": "2022-03-23T10:00:26Z"}, {"author": "Paul Wouters", "text": "thanks<br/>", "time": "2022-03-23T10:00:26Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "Yeah...<br/>", "time": "2022-03-23T10:00:28Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "You need a protocol to exist before you can model it<br/>", "time": "2022-03-23T10:00:35Z"}, {"author": "Eric Rescorla", "text": "You may find reading ProVerif scripts somewhat challenging<br/>", "time": "2022-03-23T10:01:45Z"}, {"author": "Christopher Patton", "text": "lol<br/>", "time": "2022-03-23T10:02:08Z"}, {"author": "jhoyla", "text": "@caw could you dump the link to the GH in chat?<br/>", "time": "2022-03-23T10:02:10Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Is the COVID officer going to come crack down on the physical line?&nbsp;&nbsp;I<br/>thought we were supposed to stay in our chair until it was time to<br/>talk<br/>", "time": "2022-03-23T10:02:24Z"}, {"author": "Robin Wilton", "text": "@Arnaud: Vincent's goal was a \"Symbolic Analysis of Privacy for TLS 1.3 with ECH\"... not to model configurations where ECH is intentionally undermined at the server end.<br/>", "time": "2022-03-23T10:02:26Z"}, {"author": "Mike Ounsworth", "text": "Sounds like we need to definitively decide if network inspection is in-scope for IETF or not. Are we obliged to design protocols to facilitate it? Are we obliged to recommend configurations to facilitate it?<br/>", "time": "2022-03-23T10:02:46Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Mike: isn't that covered in RFC 2804?<br/>", "time": "2022-03-23T10:03:11Z"}, {"author": "Martin Thomson", "text": "if both back end servers have two valid configurations that can reach them, in theory they could still be indistinguishable<br/>", "time": "2022-03-23T10:03:19Z"}, {"author": "Sean Turner", "text": "we are not obligated to design protocols that facilitate it. That is settled long ago.<br/>", "time": "2022-03-23T10:03:23Z"}, {"author": "Martin Thomson", "text": "I think<br/>", "time": "2022-03-23T10:03:23Z"}, {"author": "Christopher Wood", "text": "Technical report: <a href=\"https://hal.inria.fr/hal-03594482/document\" rel=\"nofollow\">https://hal.inria.fr/hal-03594482/document</a><br/>", "time": "2022-03-23T10:03:32Z"}, {"author": "Richard Barnes", "text": "I don't think it's really even an RFC 2804 question.&nbsp;&nbsp;it's just a question of where the ends of the protocol are.<br/>", "time": "2022-03-23T10:03:37Z"}, {"author": "Christopher Wood", "text": "Model: <a href=\"https://gitlab.inria.fr/chevalvi/echo_tls\" rel=\"nofollow\">https://gitlab.inria.fr/chevalvi/echo_tls</a><br/>", "time": "2022-03-23T10:03:37Z"}, {"author": "Michael Jenkins", "text": "@ben in my experience the in-room chairs aren't really managing the in-room mics. Either they haven't been trained to do so or I've been in rooms with so few people it's not been an issue.<br/>", "time": "2022-03-23T10:03:44Z"}, {"author": "Sean Turner", "text": "And, we basically re-litigated that during the draft-green discussions.<br/>", "time": "2022-03-23T10:03:45Z"}, {"author": "Paul Wouters", "text": "We fight for the (end)user !&nbsp;&nbsp;-- Tron<br/>", "time": "2022-03-23T10:04:16Z"}, {"author": "Mike Ounsworth", "text": "RFC 2804. Yup. Seems definitive. Now, why does this keep coming up at every WG session?<br/>", "time": "2022-03-23T10:04:42Z"}, {"author": "Deb Cooley", "text": "hope springs eternal?<br/>", "time": "2022-03-23T10:04:58Z"}, {"author": "Andrew Campling", "text": "@Sean \u201csettled long ago\u201d presumably doesn\u2019t prohibit an issue being re-examined given changing circumstances.<br/>", "time": "2022-03-23T10:05:13Z"}, {"author": "Sean Turner", "text": "@Mike This is the battle ground<br/>", "time": "2022-03-23T10:05:17Z"}, {"author": "Sean Turner", "text": "@Andrew - sure but we just redid it two years ago. Nothing new has really been added.<br/>", "time": "2022-03-23T10:05:40Z"}, {"author": "sftcd-x-x", "text": "re-visiting the deliberate mitm issue so often gets a little tedious I have to say<br/>", "time": "2022-03-23T10:05:48Z"}, {"author": "Martin Thomson", "text": "if someone had new information, that might be different, but claiming that information is new doesn't make it so<br/>", "time": "2022-03-23T10:06:01Z"}, {"author": "Arnaud Taddei", "text": "@Robin I know what Vincent is trying to do and quite fascinating. I think there would be a lot of value to ask the same thing in a real environment<br/>", "time": "2022-03-23T10:06:05Z"}, {"author": "Eric Rescorla", "text": "@Andrew: yes, if you want to reoepn the question of RFC 2804 in IETF as a whole, sure.<br/>", "time": "2022-03-23T10:06:10Z"}, {"author": "Eric Rescorla", "text": "@Arnaud: well, I'm not sure what you mean by a \"real environment\". The vast majority of clients do not have MITM proxies<br/>", "time": "2022-03-23T10:06:29Z"}, {"author": "sftcd-x-x", "text": "@arnaud: \"real! != MITM proxies<br/>", "time": "2022-03-23T10:06:40Z"}, {"author": "Eric Rescorla", "text": "And this model *does* capture the rest of what you are asking, I believe<br/>", "time": "2022-03-23T10:06:45Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "&gt; hybrid means using multiple algorithms<br/>(probably also describes HPKE, but I hope we have unconfused ourselves<br/>on this point for the purpose of this session)<br/>", "time": "2022-03-23T10:06:49Z"}, {"author": "Arnaud Taddei", "text": "@Eric, this is bizarre, I have all tier 1 500 fortune enterprises that disagree<br/>", "time": "2022-03-23T10:07:01Z"}, {"author": "Rich Salz", "text": "STOP<br/>", "time": "2022-03-23T10:07:11Z"}, {"author": "Eric Rescorla", "text": "@arnaud: I can show you our measurements<br/>", "time": "2022-03-23T10:07:21Z"}, {"author": "sftcd-x-x", "text": "1500 web servers is a tiny numbers<br/>", "time": "2022-03-23T10:07:26Z"}, {"author": "Rich Salz", "text": "This is not the place for restarting this discussion.<br/>", "time": "2022-03-23T10:07:26Z"}, {"author": "Rich Salz", "text": "Please STOP everyone.<br/>", "time": "2022-03-23T10:07:37Z"}, {"author": "Martin Thomson", "text": "+1 r$, this is the time we have for talking about hybrid key exchange<br/>", "time": "2022-03-23T10:07:48Z"}, {"author": "Dennis Jackson", "text": "Thanks Rich.<br/>", "time": "2022-03-23T10:07:49Z"}, {"author": "Arnaud Taddei", "text": "Well, it seems we have a problem then if you guys are not willing to listen.<br/>", "time": "2022-03-23T10:07:50Z"}, {"author": "Mike Ounsworth", "text": "+1 @Rich<br/>", "time": "2022-03-23T10:07:51Z"}, {"author": "David Schinazi", "text": "+1 Rich<br/>", "time": "2022-03-23T10:07:56Z"}, {"author": "Sean Turner", "text": "Yep - we settled this.<br/>", "time": "2022-03-23T10:08:04Z"}, {"author": "jhoyla", "text": "@Rich I don't know if you can restart a discussion that has never really stopped :P <br/>", "time": "2022-03-23T10:08:13Z"}, {"author": "Rich Salz", "text": "Let's talk about how proverif uses (* broken comment indicators *)<br/>", "time": "2022-03-23T10:08:41Z"}, {"author": "Mike Ounsworth", "text": "Clearly this needs to be discussed. So what is the right forum? TLS WG mailist?<br/>", "time": "2022-03-23T10:08:44Z"}, {"author": "Sean Turner", "text": "ietf@ietf.org<br/>", "time": "2022-03-23T10:08:56Z"}, {"author": "Eric Rescorla", "text": "ietf@<br/>", "time": "2022-03-23T10:08:58Z"}, {"author": "Eric Rescorla", "text": "because it's a general question about IETF policy<br/>", "time": "2022-03-23T10:09:09Z"}, {"author": "Thom Wiggers", "text": "jhoyla: this is the name I was failing to come up with again and again :-)<br/>", "time": "2022-03-23T10:09:11Z"}, {"author": "Arnaud Taddei", "text": "I can accept not to make the discussion here but we need to have the discussion as it is not going to fly in the real world<br/>", "time": "2022-03-23T10:09:14Z"}, {"author": "sftcd-x-x", "text": "@mikeO: this has all been discussed, endlessly, please GOTO mail archives <br/>", "time": "2022-03-23T10:09:16Z"}, {"author": "Eric Rescorla", "text": "If you want to discuss the fraction of clients that have MITM proxies, then tls@ is appropriate. Happy to share our data on this<br/>", "time": "2022-03-23T10:09:36Z"}, {"author": "Thom Wiggers", "text": "This draft is very mature afaict<br/>", "time": "2022-03-23T10:11:02Z"}, {"author": "Mike Ounsworth", "text": "@Arnaud, there's your answer: if you want to challenge RFC 2804, you should do so on the ietf@ietf.org list.<br/>", "time": "2022-03-23T10:11:18Z"}, {"author": "Richard Barnes", "text": "@Arnaud - I think your scenario is simply out of scope.&nbsp;&nbsp;A TLS inspection device terminates and re-initiates TLS.&nbsp;&nbsp;TLS works unmodified because the inspection agent is a back-to-back agent, and there is no attempt to assure cryptographic security properties across the break/reinitiate boundary.<br/>", "time": "2022-03-23T10:11:20Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Is everyone or just me seeing Vincent in the queue but with no<br/>requested permissions?<br/>", "time": "2022-03-23T10:11:30Z"}, {"author": "Thom Wiggers", "text": "@kaduk: we see this in the room as well<br/>", "time": "2022-03-23T10:11:54Z"}, {"author": "Arnaud Taddei", "text": "Ok so I will have to endure the mailing lists then<br/>", "time": "2022-03-23T10:12:08Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Thom: thanks.<br/>", "time": "2022-03-23T10:12:10Z"}, {"author": "Thom Wiggers", "text": "@meetecho Vincent seems stuck in the queue without a request<br/>", "time": "2022-03-23T10:12:29Z"}, {"author": "Sean Turner", "text": "@arnaud: that's pretty much the IETF process.<br/>", "time": "2022-03-23T10:12:31Z"}, {"author": "Meetecho", "text": "Kaduk: Vincent is in queue to present slides<br/>", "time": "2022-03-23T10:12:33Z"}, {"author": "Meetecho", "text": "Maybe by accident?<br/>", "time": "2022-03-23T10:12:38Z"}, {"author": "Meetecho", "text": "That's not the \"can I talk\" icon<br/>", "time": "2022-03-23T10:12:46Z"}, {"author": "jhoyla", "text": "@Arnaud <a href=\"https://malcolm.cloudflare.com/\" rel=\"nofollow\">https://malcolm.cloudflare.com/</a><br/>", "time": "2022-03-23T10:12:50Z"}, {"author": "Alexey Melnikov", "text": "+1 to Stephen<br/>", "time": "2022-03-23T10:13:08Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "I think I still am confused about what Arnoud is asking for.<br/>We can acknowledge that there are some companies that are using<br/>in-network devices to attempt to inspect their TLS traffic, that's<br/>easy.&nbsp;&nbsp;We have IETF consensus that we aren't obliged to design<br/>technical mechansisms to enable that behavior.<br/>", "time": "2022-03-23T10:13:11Z"}, {"author": "Christopher Wood", "text": "@sftcd -- WGLC does not mean \"publish as RFC.\" Parking is totally appropriate.<br/>", "time": "2022-03-23T10:13:16Z"}, {"author": "Bas Westerbaan", "text": "I agree this is the right time. NIST is bound to announce any time now.<br/>", "time": "2022-03-23T10:13:30Z"}, {"author": "Yoav Nir", "text": "Not sure. I don't think we've parked documents before.<br/>", "time": "2022-03-23T10:13:40Z"}, {"author": "Martin Thomson", "text": "I'm not sure that I agree with sftcd.&nbsp;&nbsp;This is being used in anger.<br/>", "time": "2022-03-23T10:14:08Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "@Meetech: right, I know&nbsp;&nbsp;what the \"request to share slides\" icon looks<br/>like, and I saw it for Vincent when he first was trying to present.&nbsp;&nbsp;I<br/>don't see it now.&nbsp;&nbsp;But I don't feel a need to worry about a single U/I<br/>glitch right now :)<br/>", "time": "2022-03-23T10:14:13Z"}, {"author": "jhoyla", "text": "By the end of the month.<br/>", "time": "2022-03-23T10:14:54Z"}, {"author": "jhoyla", "text": "Or so they say.<br/>", "time": "2022-03-23T10:14:59Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "@Meetecho: whoops, typo'd your name in the previous<br/>", "time": "2022-03-23T10:15:00Z"}, {"author": "Richard Barnes", "text": "why do we care about NIST finishing?&nbsp;&nbsp;this seems like a generic combinator<br/>", "time": "2022-03-23T10:15:00Z"}, {"author": "jhoyla", "text": "+1 @rlb<br/>", "time": "2022-03-23T10:15:21Z"}, {"author": "jhoyla", "text": "(and ekr)<br/>", "time": "2022-03-23T10:15:27Z"}, {"author": "Martin Thomson", "text": "does this even depend on having a PQ KEM?<br/>", "time": "2022-03-23T10:15:30Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "It seems possible to publish the spec about how to do the thing in the<br/>abstract and register actual codepoints for specific combinations of<br/>values later, after the RFC is published<br/>", "time": "2022-03-23T10:15:42Z"}, {"author": "Martin Thomson", "text": "I mean, we can glue RSA and ECDH together, right?<br/>", "time": "2022-03-23T10:15:45Z"}, {"author": "Florence D", "text": "Sec Cons may depend on the algorithms&nbsp;&nbsp;(e.g. the impact of using the FO transform on the security properties).<br/>", "time": "2022-03-23T10:16:03Z"}, {"author": "Deb Cooley", "text": "because you love complexity?<br/>", "time": "2022-03-23T10:16:05Z"}, {"author": "Yoav Nir", "text": "There's a difference between a generic mechanism for 100-byte key/cert/signature and a 100KB key/cert/signature<br/>", "time": "2022-03-23T10:16:08Z"}, {"author": "Sean Turner", "text": "@kaduk technically yes we could do that<br/>", "time": "2022-03-23T10:16:10Z"}, {"author": "jhoyla", "text": "@MT no, it doesn't, but you only get the security of the most secure algorithm, so if they're both classical you don't have PQ resistance. <br/>", "time": "2022-03-23T10:16:36Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Yoav: sure, but that's out of scope, since this is for key exchange<br/>", "time": "2022-03-23T10:16:40Z"}, {"author": "Richard Barnes", "text": "it seems like you could also address length ambiguity by properly encoding the hash input?<br/>", "time": "2022-03-23T10:16:44Z"}, {"author": "Richard Barnes", "text": "i am ending every sentence with ? bc i am not quite awake?<br/>", "time": "2022-03-23T10:17:11Z"}, {"author": "Martin Thomson", "text": "jhoyla: not my point; my point was exactly yours: this is a way to combine algorithms in a way that ensures you get the strongest of the set.<br/>", "time": "2022-03-23T10:17:13Z"}, {"author": "Martin Thomson", "text": "It doesn't help with PQ until we have a PQ-secure algorithm, but it does work with classic security if you had no faith in a classic algorithm<br/>", "time": "2022-03-23T10:17:45Z"}, {"author": "Dennis Jackson", "text": "although you do get the memory-safety property of the weakest :-P<br/>", "time": "2022-03-23T10:17:47Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Barnes: I don't think it's length ambiguity but rather controlling<br/>hash state.&nbsp;&nbsp;But maybe I'm confused!<br/>", "time": "2022-03-23T10:17:47Z"}, {"author": "Martin Thomson", "text": "not that you would want to do that, of course<br/>", "time": "2022-03-23T10:17:52Z"}, {"author": "jhoyla", "text": "I think my Extended Key Schedule draft (sadly expired) would fix this issue by adding the necessary framing .<br/>", "time": "2022-03-23T10:17:54Z"}, {"author": "Yoav Nir", "text": "@kaduk: I should have included \"key part\" instead of \"key\"<br/>", "time": "2022-03-23T10:18:55Z"}, {"author": "Sean Turner", "text": "Let's keep the comment as brief as possible.<br/>", "time": "2022-03-23T10:18:56Z"}, {"author": "jhoyla", "text": "Cryptanalysis on one foot / off the cuff is always hard. <br/>", "time": "2022-03-23T10:19:35Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "But you have to simultaneously collide transcript and keys...<br/>", "time": "2022-03-23T10:19:36Z"}, {"author": "Scott Fluhrer", "text": "I don't see how this 'downgrade attack' can work.&nbsp;&nbsp;With this draft, we consider only specific groups, for example, X25519+NTRU.&nbsp;&nbsp;The only issue if we were to define a 'named group' that included a variable length group<br/>", "time": "2022-03-23T10:20:36Z"}, {"author": "David Benjamin", "text": "We don't need a filter in the negotiation, just to not define a bad code point.<br/>", "time": "2022-03-23T10:20:45Z"}, {"author": "David Benjamin", "text": "Since each combo gets its own code point.<br/>", "time": "2022-03-23T10:21:02Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Oh hey, davidben is here.<br/>", "time": "2022-03-23T10:21:02Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Note that we gave you some action items earlier, while you were away<br/>:)<br/>", "time": "2022-03-23T10:21:16Z"}, {"author": "David Benjamin", "text": "Hi! Yeah, the meeting is 5am my time and I overslept. :(<br/>", "time": "2022-03-23T10:21:22Z"}, {"author": "Martin Thomson", "text": "the combiner was too unpleasant to consider<br/>", "time": "2022-03-23T10:21:23Z"}, {"author": "Bas Westerbaan", "text": "Is there an application for variable-length shared secrets? I think restricting to fixed-length ss is very reasonable.<br/>", "time": "2022-03-23T10:21:33Z"}, {"author": "David Benjamin", "text": "Oh, good to know... what were the action items?<br/>", "time": "2022-03-23T10:21:37Z"}, {"author": "dkg", "text": "MT: thanks, that was the critical bit of summary <br/>", "time": "2022-03-23T10:21:48Z"}, {"author": "Mike Ounsworth", "text": "Is Aviram et al. a generic attack on NIST SP 800-56Cr2 with Z' = Z || T&nbsp;&nbsp;?<br/>", "time": "2022-03-23T10:22:16Z"}, {"author": "Rich Salz", "text": "Text for one of the issues you brought up on 8446bis<br/>", "time": "2022-03-23T10:22:16Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "off the top of my head, propose text to clarify that the negotiated<br/>hash is used for message_hash injection, hopefully as the \"smallest<br/>change we can get away with\"<br/>", "time": "2022-03-23T10:22:18Z"}, {"author": "Martin Thomson", "text": "davidben: you need to provide a fix for RFC 8446 that addresses the question of whether CH1 or CH2 determines connection parameters when there is HRR<br/>", "time": "2022-03-23T10:22:31Z"}, {"author": "Arnaud Taddei", "text": "@jhoyla, thank you for the link<br/>", "time": "2022-03-23T10:22:35Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "There may have been one more; hopefully the minutes will know.<br/>", "time": "2022-03-23T10:22:36Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Yeah, MT got it, thanks<br/>", "time": "2022-03-23T10:22:51Z"}, {"author": "Martin Thomson", "text": "the one that kaduk identified is, I think, on ekr's plate<br/>", "time": "2022-03-23T10:22:52Z"}, {"author": "Eric Rescorla", "text": "@davidben: or, if you feel lazy, press \"close\" :)<br/>", "time": "2022-03-23T10:22:59Z"}, {"author": "David Benjamin", "text": "Oh dear. So basically solve the disaster that is HRR. Piece of cake! :D<br/>", "time": "2022-03-23T10:23:18Z"}, {"author": "Christopher Patton", "text": "lol<br/>", "time": "2022-03-23T10:23:32Z"}, {"author": "Eric Rescorla", "text": "Correct, that is on my plate, but I plan to be explicit about which hash is used everywhere, which is what davidben and I discused<br/>", "time": "2022-03-23T10:23:34Z"}, {"author": "Scott Fluhrer", "text": "How to upgrade the key combiner: when we define a new hybrid named group, include the combiner for that named group in the definition<br/>", "time": "2022-03-23T10:23:36Z"}, {"author": "dkg", "text": "isn't each new algorithm codepoint basically KEX1+KEX2+combiner choice?<br/>", "time": "2022-03-23T10:23:38Z"}, {"author": "Eric Rescorla", "text": "@dkg: I guess you're right<br/>", "time": "2022-03-23T10:23:55Z"}, {"author": "dkg", "text": "what Scott said<br/>", "time": "2022-03-23T10:24:13Z"}, {"author": "Martin Thomson", "text": "\"\"\"&nbsp;&nbsp; TLS 1.3 does not require that ephemeral public keys be used only in a<br/>&nbsp;&nbsp; single key exchange session; some implementations may reuse them, at<br/>&nbsp;&nbsp; the cost of limited forward secrecy.&nbsp;&nbsp;As a result, any KEM used in<br/>&nbsp;&nbsp; the manner described in this document MUST explicitly be designed to<br/>&nbsp;&nbsp; be secure in the event that the public key is reused, such as<br/>&nbsp;&nbsp; achieving IND-CCA2 security or having a transform like the Fujisaki-<br/>&nbsp;&nbsp; Okamoto transform [FO] [HHK] applied.&nbsp;&nbsp;While it is recommended that<br/>&nbsp;&nbsp; implementations avoid reuse of KEM public keys, implementations that<br/>&nbsp;&nbsp; do reuse KEM public keys MUST ensure that the number of reuses of a<br/>&nbsp;&nbsp; KEM public key abides by any bounds in the specification of the KEM<br/>&nbsp;&nbsp; or subsequent security analyses.&nbsp;&nbsp;Implementations MUST NOT reuse<br/>&nbsp;&nbsp; randomness in the generation of KEM ciphertexts.\"\"\"<br/>", "time": "2022-03-23T10:25:35Z"}, {"author": "Eric Rescorla", "text": "@DavidBen: the actual ask is \"propose whatever minimal HRR changes you think improve the situation without making things more confusing\"<br/>", "time": "2022-03-23T10:25:36Z"}, {"author": "Martin Thomson", "text": "I thought that this was about clarifying the risks of either approach and identifying where there is no real choice<br/>", "time": "2022-03-23T10:26:02Z"}, {"author": "Martin Thomson", "text": "(between CH1 and CH2<br/>", "time": "2022-03-23T10:26:06Z"}, {"author": "Eric Rescorla", "text": "That's a better phrasing<br/>", "time": "2022-03-23T10:26:20Z"}, {"author": "Eric Rescorla", "text": "and keep it to one paragraph :)<br/>", "time": "2022-03-23T10:26:52Z"}, {"author": "Sean Turner", "text": "We are moving the kitten updates header to the mailing list. We ran over on the WG I-Ds.<br/>", "time": "2022-03-23T10:26:52Z"}, {"author": "Richard Barnes", "text": "browser / server folks -- what are the stats looking like on KEX these days?<br/>", "time": "2022-03-23T10:27:03Z"}, {"author": "Yoav Nir", "text": "I thought we had already deprecated them in 1.3, no?<br/>", "time": "2022-03-23T10:27:17Z"}, {"author": "Rich Salz", "text": "X25519 dominates<br/>", "time": "2022-03-23T10:27:20Z"}, {"author": "Martin Thomson", "text": "99.29% ECDH<br/>", "time": "2022-03-23T10:28:02Z"}, {"author": "Martin Thomson", "text": "the rest is RSA<br/>", "time": "2022-03-23T10:28:22Z"}, {"author": "David Benjamin", "text": "Or 100% if you didn't implement FFDH at all. :-)<br/>", "time": "2022-03-23T10:28:24Z"}, {"author": "Richard Barnes", "text": "interesting, thansk<br/>", "time": "2022-03-23T10:28:28Z"}, {"author": "David Benjamin", "text": "Oh you mean including 1.2. Sorry, misunderstood.<br/>", "time": "2022-03-23T10:28:39Z"}, {"author": "dkg", "text": "when you say \"e-mail\" it would be useful to clarify that you're talking about SMTP and IMAP<br/>", "time": "2022-03-23T10:28:45Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "Is this intended to deprecate in 1.2 and below?<br/>", "time": "2022-03-23T10:28:54Z"}, {"author": "Eric Rescorla", "text": "I think so<br/>", "time": "2022-03-23T10:28:59Z"}, {"author": "Yoav Nir", "text": "Not much point in deprecating them for 1.2 and lower, because if they're upgrading the software, them might as well upgrade to 1.3 rather than 1.2-with-this-new-RFC<br/>", "time": "2022-03-23T10:28:59Z"}, {"author": "dkg", "text": "there are other forms of e-mail encryption<br/>", "time": "2022-03-23T10:29:00Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "You can update your config without updating your software.<br/>", "time": "2022-03-23T10:29:15Z"}, {"author": "sftcd-x-x", "text": "@dkg: its usually smtp stats IIUC<br/>", "time": "2022-03-23T10:29:20Z"}, {"author": "Sean Turner", "text": "@Yoav yep this the regular debate about deprecation<br/>", "time": "2022-03-23T10:29:32Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Are there other forms of email servers?&nbsp;&nbsp;(Don't answer that.)<br/>", "time": "2022-03-23T10:29:34Z"}, {"author": "Yoav Nir", "text": "And I think UTA has had a configuration recommendation document about how to configure 1.2.<br/>", "time": "2022-03-23T10:29:59Z"}, {"author": "Eric Rescorla", "text": "@kaduk: Gmail!<br/>", "time": "2022-03-23T10:30:16Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "A certain 7525bis?<br/>", "time": "2022-03-23T10:30:42Z"}, {"author": "Martin Thomson", "text": "For ECDH: X25519 78.84% P-256 19.65% P-384 1.44%<br/>", "time": "2022-03-23T10:30:54Z"}, {"author": "Yoav Nir", "text": "Yeah, that's the one. In that case, they're in the wrong room<br/>", "time": "2022-03-23T10:31:12Z"}, {"author": "Martin Thomson", "text": "stats are from our nightly builds<br/>", "time": "2022-03-23T10:31:14Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "LEaving 0.07% \"other\"?<br/>", "time": "2022-03-23T10:31:17Z"}, {"author": "sftcd-x-x", "text": "@mt: any clue who/what uses p384?<br/>", "time": "2022-03-23T10:31:18Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "Clearly we need fully turing complete configurations so that updating<br/>to more modern protocols is equivalent to updating the configuration.<br/>", "time": "2022-03-23T10:31:24Z"}, {"author": "Martin Thomson", "text": "kaduk: we get some P-521<br/>", "time": "2022-03-23T10:31:26Z"}, {"author": "Martin Thomson", "text": "sftcd: we don't collect stats on sites<br/>", "time": "2022-03-23T10:31:38Z"}, {"author": "Eric Rescorla", "text": "@svaldex: isn't that called \"the web\"?<br/>", "time": "2022-03-23T10:31:38Z"}, {"author": "Maarten Aertsen", "text": "Re: smtp is opportunistic, we have active use of starttls+dane in the Netherlands. And now Microsoft has actually turned it on for outbound email from O365, this may grow elsewhere too. I like this draft very much btw.<br/>", "time": "2022-03-23T10:31:48Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Hmm, nightly builds are going to bias towards early adopters in<br/>general, though.<br/>", "time": "2022-03-23T10:31:53Z"}, {"author": "Richard Barnes", "text": "@sftcd Some Navy folks asked for 384 in MLS<br/>", "time": "2022-03-23T10:32:00Z"}, {"author": "Martin Thomson", "text": "kaduk: you would be surprised; it's our Beta that biases toward the more modern TLS<br/>", "time": "2022-03-23T10:32:13Z"}, {"author": "Rich Salz", "text": "@sftcd-x-x-x-x: you'd be surprised. government/hospitality<br/>", "time": "2022-03-23T10:32:19Z"}, {"author": "Richard Barnes", "text": "(@Britta in particular :) )<br/>", "time": "2022-03-23T10:32:28Z"}, {"author": "Christopher Patton", "text": "1.3 supports FFDHE<br/>", "time": "2022-03-23T10:32:36Z"}, {"author": "Martin Thomson", "text": "Christopher Patton: but it's not widely used<br/>", "time": "2022-03-23T10:32:56Z"}, {"author": "Thom Wiggers", "text": "OpenSSL e.g. does not implement it last time I checked<br/>", "time": "2022-03-23T10:33:08Z"}, {"author": "Christopher Patton", "text": "does 8446 say anything about static FFDHE?<br/>", "time": "2022-03-23T10:33:11Z"}, {"author": "Britta Hale", "text": "@sftcd-x-x: the NSA has it as a requirement for certain use classifications<br/>", "time": "2022-03-23T10:33:18Z"}, {"author": "Deb Cooley", "text": "@sftcd-x-x:&nbsp;&nbsp;we do indeed.<br/>", "time": "2022-03-23T10:33:35Z"}, {"author": "Eric Rescorla", "text": "Is the answer to take it to UTA?<br/>", "time": "2022-03-23T10:33:42Z"}, {"author": "Martin Thomson", "text": "we implemented the ffdhe groups, but Firefox doesn't have them turned on<br/>", "time": "2022-03-23T10:33:45Z"}, {"author": "Eric Rescorla", "text": "Could we just add this to 7525-bis?<br/>", "time": "2022-03-23T10:33:51Z"}, {"author": "Richard Barnes", "text": "turning off TLS features seems appropriate to TLS<br/>", "time": "2022-03-23T10:33:57Z"}, {"author": "Deb Cooley", "text": "static FFDHE is an oxymoron?<br/>", "time": "2022-03-23T10:33:59Z"}, {"author": "Rich Salz", "text": "imagine a hotel that wants to keep \"who registered\" private from post-facto disclosure, because they're a favored hotel of us govt.<br/>", "time": "2022-03-23T10:34:28Z"}, {"author": "Alexey Melnikov", "text": "I interpreted this as suggestion to have a single document with the one in UTA<br/>", "time": "2022-03-23T10:34:32Z"}, {"author": "Carrick", "text": "@Deb Yes, but in practice apparently people still reuse key material when using FFDHE<br/>", "time": "2022-03-23T10:34:33Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "OpenSSL implements FFDHE for TLS 1.3 only, IIRC<br/>", "time": "2022-03-23T10:34:34Z"}, {"author": "Christopher Patton", "text": "@Deb sorry I meant static FFDH :)<br/>", "time": "2022-03-23T10:34:42Z"}, {"author": "Martin Thomson", "text": "I'm OK with this being adopted and published.&nbsp;&nbsp;it's the right advice to be giving.&nbsp;&nbsp;I have no preference between a standalone thing and 7525-bis<br/>", "time": "2022-03-23T10:34:48Z"}, {"author": "Richard Barnes", "text": "nothing as fun as a good jurisdictional fight<br/>", "time": "2022-03-23T10:34:56Z"}, {"author": "Deb Cooley", "text": "@carrick - yeah people are dumb<br/>", "time": "2022-03-23T10:34:59Z"}, {"author": "Yoav Nir", "text": "\"updates 7525\" is also good.<br/>", "time": "2022-03-23T10:35:20Z"}, {"author": "Rich Salz", "text": "I think TLS makes sense to say that certain TLS algs should now be avoided.<br/>", "time": "2022-03-23T10:35:42Z"}, {"author": "Yoav Nir", "text": "I think we said this by not including them in 1.3<br/>", "time": "2022-03-23T10:36:03Z"}, {"author": "Rich Salz", "text": "But David's point: we did it for old versions and old protocols already. This is just one more.<br/>", "time": "2022-03-23T10:36:55Z"}, {"author": "Eric Rescorla", "text": "Can I propose that the chairs sort out the WG?<br/>", "time": "2022-03-23T10:36:57Z"}, {"author": "Eric Rescorla", "text": "With the other chairs<br/>", "time": "2022-03-23T10:37:03Z"}, {"author": "Maarten Aertsen", "text": "Drafts like these have communication value to industry/operators.<br/>", "time": "2022-03-23T10:37:07Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Yes, let the chairs talk about venue<br/>", "time": "2022-03-23T10:37:09Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "<a href=\"https://github.com/openssl/openssl/pull/8178\" rel=\"nofollow\">https://github.com/openssl/openssl/pull/8178</a> is \"TLS1.3 FFDHE<br/>support\", since we mentioned that previously<br/>", "time": "2022-03-23T10:37:40Z"}, {"author": "David Benjamin", "text": "+1 to having the chairs deal with this. Though, as an implementor, I've definitely found these kinds of drafts helpful and support this work as-is.<br/>", "time": "2022-03-23T10:37:43Z"}, {"author": "sftcd-x-x", "text": "+1 to letting chairs/ADs figure it out, but also +1 to doing the deprecations<br/>", "time": "2022-03-23T10:37:53Z"}, {"author": "Yoav Nir", "text": "It's why we pay them the big bucks<br/>", "time": "2022-03-23T10:38:19Z"}, {"author": "Roman Danyliw", "text": "Action caught.&nbsp;&nbsp;AD+Chairs will coordinate.<br/>", "time": "2022-03-23T10:38:37Z"}, {"author": "jhoyla", "text": "<a href=\"https://blog.cloudflare.com/sizing-up-post-quantum-signatures/\" rel=\"nofollow\">https://blog.cloudflare.com/sizing-up-post-quantum-signatures/</a><br/>", "time": "2022-03-23T10:42:21Z"}, {"author": "dkg", "text": "what does the / represent in these figures?&nbsp;&nbsp;does it separate two different PQ algos?&nbsp;&nbsp;or is it up/down ?<br/>", "time": "2022-03-23T10:45:07Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "might have to ask at the mic<br/>", "time": "2022-03-23T10:45:52Z"}, {"author": "Richard Barnes", "text": "just put a bloom filter in the ClientHello<br/>", "time": "2022-03-23T10:46:47Z"}, {"author": "sftcd-x-x", "text": "just wondering: what's the rate of change of the WebPKI ICA list? (i.e. how often is any change made)<br/>", "time": "2022-03-23T10:46:47Z"}, {"author": "Martin Thomson", "text": "sftcd: we asked the same question and the answer is that we get a new intermediate every day or so<br/>", "time": "2022-03-23T10:47:06Z"}, {"author": "dkg", "text": "that's good data to publicize somewhere<br/>", "time": "2022-03-23T10:47:24Z"}, {"author": "Richard Barnes", "text": "also kinda terrifying<br/>", "time": "2022-03-23T10:47:33Z"}, {"author": "sftcd-x-x", "text": "interesting, that's faster than I'd have expected<br/>", "time": "2022-03-23T10:47:35Z"}, {"author": "dkg", "text": "and do you remove ICAs at about the same rate?<br/>", "time": "2022-03-23T10:47:43Z"}, {"author": "Martin Thomson", "text": "we don't have precise stats, so that's a sort of eyeballing of the log<br/>", "time": "2022-03-23T10:47:43Z"}, {"author": "dkg", "text": "(assuming removals happen based on expiration mainly)<br/>", "time": "2022-03-23T10:47:53Z"}, {"author": "Richard Barnes", "text": "@Martin shouldn't CCADB tell you?<br/>", "time": "2022-03-23T10:47:55Z"}, {"author": "Martin Thomson", "text": "Richard: yes, we looked at a secondary source, but it is driven from CCADB<br/>", "time": "2022-03-23T10:48:22Z"}, {"author": "dkg", "text": "if there are 1500 ICAs and ICA cert duration is 4 years and they're evenly distributed, that's ~~1 expiration per day<br/>", "time": "2022-03-23T10:49:11Z"}, {"author": "sftcd-x-x", "text": "enough of that math magic dkg!<br/>", "time": "2022-03-23T10:49:40Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Doesn't everyone want to be a mathemagician?<br/>", "time": "2022-03-23T10:50:00Z"}, {"author": "Bas Westerbaan", "text": "Clients can know they have an old list.<br/>", "time": "2022-03-23T10:50:45Z"}, {"author": "Benjamin Schwartz", "text": "Represent list as a URL :) Server can fetch it if unrecognized<br/>", "time": "2022-03-23T10:50:56Z"}, {"author": "Christopher Patton", "text": "Good point David<br/>", "time": "2022-03-23T10:51:08Z"}, {"author": "sftcd-x-x", "text": "@bas: aren't some of these lists in the OS rather than the application client?<br/>", "time": "2022-03-23T10:51:12Z"}, {"author": "Martin Thomson", "text": "the webPKI case that is most tricky is technically constrained intermediaries.<br/>", "time": "2022-03-23T10:51:13Z"}, {"author": "Christopher Patton", "text": "FWIW, I think this is something worth working on<br/>", "time": "2022-03-23T10:51:19Z"}, {"author": "dkg", "text": "Ben: b/c URL contents never change?<br/>", "time": "2022-03-23T10:51:20Z"}, {"author": "jhoyla", "text": "@Ben Schwartz that's fancy<br/>", "time": "2022-03-23T10:51:38Z"}, {"author": "Eric Rescorla", "text": "of course, arguably we're sort of running this experiment, just w/o the extension :)<br/>", "time": "2022-03-23T10:51:40Z"}, {"author": "Benjamin Schwartz", "text": "dkg: We can demand that it's immutable, or just use HTTP cache lifetimes<br/>", "time": "2022-03-23T10:51:41Z"}, {"author": "Bas Westerbaan", "text": "@sftcd-x-x that doesn't prevent the OS from recording how up-to-date it is or updating it frequently<br/>", "time": "2022-03-23T10:51:41Z"}, {"author": "jhoyla", "text": "@dkg You can ensure that they don't. <br/>", "time": "2022-03-23T10:51:48Z"}, {"author": "Eric Rescorla", "text": "And our ICA preload is designed to work around it<br/>", "time": "2022-03-23T10:52:02Z"}, {"author": "Massimiliano Pala", "text": "From what I can tell, the solution seems quite prone to issues, misalignment, and results can really vary on implementations, freshness, etc. Maybe there might be some more considerations that need to be taken in consideration...<br/>", "time": "2022-03-23T10:52:08Z"}, {"author": "Eric Rescorla", "text": "It's just that servers inadvertantly do this!<br/>", "time": "2022-03-23T10:52:13Z"}, {"author": "Martin Thomson", "text": "Ben Schwartz's idea is a privacy problem<br/>", "time": "2022-03-23T10:52:20Z"}, {"author": "jhoyla", "text": "@MT isn't it the same as OCSP?<br/>", "time": "2022-03-23T10:52:46Z"}, {"author": "Richard Barnes", "text": "who is presenting?<br/>", "time": "2022-03-23T10:52:46Z"}, {"author": "dkg", "text": "it also means that clients get to force servers to load and parse arbitrary ASN.1<br/>", "time": "2022-03-23T10:52:47Z"}, {"author": "Benjamin Schwartz", "text": "Martin: Among other things!<br/>", "time": "2022-03-23T10:52:49Z"}, {"author": "Bas Westerbaan", "text": "@richard Thom Wiggers<br/>", "time": "2022-03-23T10:52:54Z"}, {"author": "Martin Thomson", "text": "jhoyla: yes.&nbsp;&nbsp;staple OCSP please.<br/>", "time": "2022-03-23T10:52:59Z"}, {"author": "jhoyla", "text": "And the solution would be to do staples if requested<br/>", "time": "2022-03-23T10:53:06Z"}, {"author": "Eric Rescorla", "text": "We are trying to eliminate OCSP<br/>", "time": "2022-03-23T10:53:07Z"}, {"author": "Christopher Wood", "text": "See CRLlite<br/>", "time": "2022-03-23T10:53:18Z"}, {"author": "dkg", "text": "even when stapled?<br/>", "time": "2022-03-23T10:53:18Z"}, {"author": "jhoyla", "text": "OCSP MUST-STAPLE is annoyingly hard. <br/>", "time": "2022-03-23T10:53:23Z"}, {"author": "Martin Thomson", "text": "stapling is perfectly fine<br/>", "time": "2022-03-23T10:53:25Z"}, {"author": "Richard Barnes", "text": "is this AuthKEM in the sense that HPKE uses that word?<br/>", "time": "2022-03-23T10:53:29Z"}, {"author": "Eric Rescorla", "text": "but we're mostly just moving to a centralized thing<br/>", "time": "2022-03-23T10:53:33Z"}, {"author": "Christopher Wood", "text": "@rlb no<br/>", "time": "2022-03-23T10:53:38Z"}, {"author": "dkg", "text": "ekr: are you saing eliminate OCSP stapling?<br/>", "time": "2022-03-23T10:53:39Z"}, {"author": "Martin Thomson", "text": "though you are right that MUST-STAPLE is rough<br/>", "time": "2022-03-23T10:53:40Z"}, {"author": "Bas Westerbaan", "text": "Personal guess: Dilithium (1.3kB pk and 2.4kB signatures)<br/>", "time": "2022-03-23T10:53:42Z"}, {"author": "Richard Barnes", "text": "@caw thanks<br/>", "time": "2022-03-23T10:53:44Z"}, {"author": "Martin Thomson", "text": "dkg: just the extra query<br/>", "time": "2022-03-23T10:53:49Z"}, {"author": "Eric Rescorla", "text": "@dkg: less saying \"eliminate\" than \"we're not going to assume it's there, and so we expect not to see too much\"<br/>", "time": "2022-03-23T10:54:07Z"}, {"author": "Sean Turner", "text": "@Bas we should started a betting pool. Or is there one that I didn't know about ;)<br/>", "time": "2022-03-23T10:54:17Z"}, {"author": "Eric Rescorla", "text": "Because there won't be any perf advantage<br/>", "time": "2022-03-23T10:54:28Z"}, {"author": "dkg", "text": "i'm just asking you to be explicit about whether you're saying \"eliminate clients actively doing OCSP querying\" or \"eliminate clients and servers using OCSP-formatted data in any context\"<br/>", "time": "2022-03-23T10:54:58Z"}, {"author": "Maarten Aertsen", "text": "Queue still closed?<br/>", "time": "2022-03-23T10:55:05Z"}, {"author": "jhoyla", "text": "@ekr Is the plan to continue enforcing MUST-STAPLE?<br/>", "time": "2022-03-23T10:55:07Z"}, {"author": "Sean Turner", "text": "I like the strike through of Rainbow ;)<br/>", "time": "2022-03-23T10:55:40Z"}, {"author": "sftcd-x-x", "text": "yeah, nice rainbow tough<br/>", "time": "2022-03-23T10:55:55Z"}, {"author": "Eric Rescorla", "text": "@jhoyla: I expect so. What fraction of certs have it<br/>", "time": "2022-03-23T10:56:14Z"}, {"author": "jhoyla", "text": "Based on my research virtually none, although I have been experimenting with one. <br/>", "time": "2022-03-23T10:57:00Z"}, {"author": "jhoyla", "text": "And keeping it up is _way_ harder than I anticipated. <br/>", "time": "2022-03-23T10:57:21Z"}, {"author": "dkg", "text": "jhoyla: what failures are you seeing?<br/>", "time": "2022-03-23T10:57:45Z"}, {"author": "sftcd-x-x", "text": "@jhoyla: why?<br/>", "time": "2022-03-23T10:57:45Z"}, {"author": "jhoyla", "text": "Making sure that the staple is in place and making sure that it gets delivered. <br/>", "time": "2022-03-23T10:58:08Z"}, {"author": "Mike Ounsworth", "text": "How does \"authKEM\" relate to \"KEMTLS\" ?<br/>", "time": "2022-03-23T10:58:14Z"}, {"author": "Bas Westerbaan", "text": "Essentially the same<br/>", "time": "2022-03-23T10:58:20Z"}, {"author": "jhoyla", "text": "Not sure why either of those things would fail, but apparently they both do. <br/>", "time": "2022-03-23T10:58:21Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Thanks Thom!<br/>", "time": "2022-03-23T10:58:47Z"}, {"author": "Christopher Patton", "text": "Thanks for the work Thom, this is an important problem to work on now.<br/>", "time": "2022-03-23T10:58:47Z"}, {"author": "jhoyla", "text": "@Mike authKEM and KEMTLS are totally different<br/>", "time": "2022-03-23T10:58:51Z"}, {"author": "Christopher Patton", "text": "*Thom and co-authors<br/>", "time": "2022-03-23T10:58:58Z"}, {"author": "dkg", "text": "jhoyla: if you could write up a note that describes the failures you're seeing in more detail, that would be really useful<br/>", "time": "2022-03-23T10:59:14Z"}, {"author": "jhoyla", "text": "KEMTLS replaces the ephemeral bit, AuthKEM replaces the signatures bit<br/>", "time": "2022-03-23T10:59:16Z"}, {"author": "Sean Turner", "text": "Thanks everybody!<br/>", "time": "2022-03-23T10:59:24Z"}, {"author": "jhoyla", "text": "@dkg That's a really good idea, will do.<br/>", "time": "2022-03-23T10:59:27Z"}, {"author": "sofiaceli", "text": "@jhoyla not true.<br/>", "time": "2022-03-23T10:59:38Z"}, {"author": "Rich Salz", "text": "thanks<br/>", "time": "2022-03-23T10:59:39Z"}, {"author": "Massimiliano Pala", "text": "thanks everybody!<br/>", "time": "2022-03-23T10:59:49Z"}, {"author": "sofiaceli", "text": "KMTLS is using both keys for auth and key exchange<br/>", "time": "2022-03-23T10:59:49Z"}, {"author": "Douglas Stebila", "text": "No @joyla KEMTLS replaces the signatures bit too. AuthKEM is a renaming of KEMTLS (with some reformatting to use HPKE etc.)<br/>", "time": "2022-03-23T10:59:51Z"}, {"author": "sofiaceli", "text": "Keys -&gt; KEMs<br/>", "time": "2022-03-23T11:00:21Z"}, {"author": "sofiaceli", "text": "AuthKEM is just the authentication part of KEMTLS, combined with a KEM in the KEX, you basically have KEMTLS<br/>", "time": "2022-03-23T11:00:57Z"}]