![](\"https://cdn.vox-cdn.com/thumbor/mFiywP9BUHDC8AIRBDYJvXdfQiA=/1400x1050/filters:format(jpeg)/cdn.vox-cdn.com/uploads/chorus_asset/file/23265504/Spider_Man_meme.jpg\")
For a second there I thought we had a chicken
", "time": "2024-03-18T23:32:56Z"}, {"author": "Deirdre Connolly", "text": "I originally thought this was 2 hours earlier (;\u00b4\u0f0e\u0eb6\u0414\u0f0e\u0eb6`)
", "time": "2024-03-18T23:32:59Z"}, {"author": "Eric Rescorla", "text": "as chair
", "time": "2024-03-18T23:32:59Z"}, {"author": "Deirdre Connolly", "text": "\n", "time": "2024-03-18T23:33:18Z"}, {"author": "Eric Rescorla", "text": "i can eat it
\n
\n:sunglasses:
Select all. Mark closed
", "time": "2024-03-18T23:33:37Z"}, {"author": "Deirdre Connolly", "text": "I wish I could reactji in MeetEcho
", "time": "2024-03-18T23:34:11Z"}, {"author": "Richard Barnes", "text": ":sunglasses:
", "time": "2024-03-18T23:34:49Z"}, {"author": "Richard Barnes", "text": "I wish emoji worked at all in MeetEcho
", "time": "2024-03-18T23:35:05Z"}, {"author": "Martin Thomson", "text": "what ekr said
", "time": "2024-03-18T23:38:40Z"}, {"author": "Stephen Farrell", "text": "boring is good
", "time": "2024-03-18T23:41:22Z"}, {"author": "Deirdre Connolly", "text": "traditional :handshake: PQ
", "time": "2024-03-18T23:41:41Z"}, {"author": "Sean Turner", "text": ":)
", "time": "2024-03-18T23:41:48Z"}, {"author": "Christopher Patton", "text": "Keep it simple for TLS!
", "time": "2024-03-18T23:44:27Z"}, {"author": "Deirdre Connolly", "text": "100 we can just ship
", "time": "2024-03-18T23:44:35Z"}, {"author": "Stephen Farrell", "text": "+1 to martin, if simple works, do simple
", "time": "2024-03-18T23:44:38Z"}, {"author": "Deirdre Connolly", "text": "The joys of TLS 1.3 doing things right in the key schedule
", "time": "2024-03-18T23:44:54Z"}, {"author": "Deirdre Connolly", "text": "yeah that
", "time": "2024-03-18T23:45:37Z"}, {"author": "Deirdre Connolly", "text": "Today?? Link please?
", "time": "2024-03-18T23:45:56Z"}, {"author": "Deirdre Connolly", "text": "on the chrome announcement
", "time": "2024-03-18T23:46:05Z"}, {"author": "Dennis Jackson", "text": "https://chromestatus.com/feature/5257822742249472
", "time": "2024-03-18T23:46:25Z"}, {"author": "Dennis Jackson", "text": "9 hours ago: https://groups.google.com/a/chromium.org/g/blink-dev/c/6xfaov3Z4yo
", "time": "2024-03-18T23:46:51Z"}, {"author": "Martin Thomson", "text": "Note that we are using Kyber, which is the draft from Bas.
", "time": "2024-03-18T23:46:53Z"}, {"author": "Deirdre Connolly", "text": "Baller, thanks Dennis
", "time": "2024-03-18T23:47:10Z"}, {"author": "Martin Thomson", "text": "Is that static ECDH?
", "time": "2024-03-18T23:47:33Z"}, {"author": "Eric Rescorla", "text": "I hope!
", "time": "2024-03-18T23:47:39Z"}, {"author": "Deirdre Connolly", "text": "Yeah uh, the number will have to change between Kyber and ML-KEM, the shared secret will change with with same inputs
", "time": "2024-03-18T23:47:42Z"}, {"author": "Dennis Jackson", "text": "Firefox - We've been shipping it in Nightly for a while, release experiment is on the way.
", "time": "2024-03-18T23:47:47Z"}, {"author": "Eric Rescorla", "text": "I think that's what the N/A means
", "time": "2024-03-18T23:47:48Z"}, {"author": "Martin Thomson", "text": "Because ECDH should be discouraged
", "time": "2024-03-18T23:47:51Z"}, {"author": "Eric Rescorla", "text": "For a moment I thought it was ECDHE
", "time": "2024-03-18T23:48:08Z"}, {"author": "Deirdre Connolly", "text": "On this point, X-Wing intends to hold off on asking for a number until ML-KEM / FIPS 203 is final
", "time": "2024-03-18T23:48:30Z"}, {"author": "Martin Thomson", "text": "FFDHE is N, ECDH is D
", "time": "2024-03-18T23:48:31Z"}, {"author": "Eric Rescorla", "text": "yeah, I just thought for a second we were discouraging ephemeral ECDH!
", "time": "2024-03-18T23:48:51Z"}, {"author": "Eric Rescorla", "text": "I think D is reasonable
", "time": "2024-03-18T23:49:18Z"}, {"author": "Eric Rescorla", "text": "for ECDH
", "time": "2024-03-18T23:49:25Z"}, {"author": "Martin Thomson", "text": "I'm OK with D for FFDHE, but it's not what we say in TLS
", "time": "2024-03-18T23:49:42Z"}, {"author": "Martin Thomson", "text": "FFDHE in TLS 1.2 is D
", "time": "2024-03-18T23:50:20Z"}, {"author": "Martin Thomson", "text": "because interoperability is challenged
", "time": "2024-03-18T23:50:30Z"}, {"author": "David Benjamin", "text": "Also shared secret is broken. https://raccoon-attack.com/
", "time": "2024-03-18T23:50:55Z"}, {"author": "Eric Rescorla", "text": "Didn't we have consensus for FFDHE == D
", "time": "2024-03-18T23:51:09Z"}, {"author": "Christopher Patton", "text": "The question about whether to discourage FFDHE is not about group size: it's about asking whether there is a use case for which ECC is not sufficient. Probably not?
", "time": "2024-03-18T23:51:31Z"}, {"author": "Martin Thomson", "text": "To recap David's comment: FFDHE Groups can be N, DHE Cipher Suites can be D
", "time": "2024-03-18T23:53:31Z"}, {"author": "Martin Thomson", "text": "FFDHE 8192 is awesome
", "time": "2024-03-18T23:53:54Z"}, {"author": "Martin Thomson", "text": "discourage fixed key DH variants in all forms
", "time": "2024-03-18T23:54:16Z"}, {"author": "Dennis Jackson", "text": "The devil makes side channels for static key exchange :-)
", "time": "2024-03-18T23:55:31Z"}, {"author": "David Benjamin", "text": "Martin Thomson said:
\n\n\nFFDHE 8192 is awesome
\n
Why worry about DoS attacks when you can just deploy incredibly slow crypto and DoS yourself!
", "time": "2024-03-18T23:55:49Z"}, {"author": "Stephen Farrell", "text": "any kind of formally blocked, depending on someone's students seems odd
", "time": "2024-03-19T00:03:09Z"}, {"author": "Eric Rescorla", "text": "well, advancing things that haven't been properly reviewed seems even more odd
", "time": "2024-03-19T00:03:40Z"}, {"author": "Jonathan Hoyland", "text": "I disagree strongly with Scott, it does break current proofs
", "time": "2024-03-19T00:05:31Z"}, {"author": "John Gray", "text": "This idea sounds great, but isn't it what CFRG does? So this Triage panel would be part of the TLS working group? Seems like other working groups would also benefit from such a panel.
", "time": "2024-03-19T00:07:43Z"}, {"author": "Eric Rescorla", "text": "CFRG doesn't do this for protocols
", "time": "2024-03-19T00:07:54Z"}, {"author": "Dennis Jackson", "text": "Not really John. CFRG is more primitives.
", "time": "2024-03-19T00:08:04Z"}, {"author": "John Gray", "text": "So shouldn't there be a working group that does what CFRG does for protocols? Maybe this panel should be isn't own group then that gives inputs to working groups?
", "time": "2024-03-19T00:09:33Z"}, {"author": "Eric Rescorla", "text": "I think it would be great to have something more generally, but I really want it for TLS, and don't want to wait for others
", "time": "2024-03-19T00:09:35Z"}, {"author": "Thom Wiggers", "text": "deidre's computer decided to do FFDHE
", "time": "2024-03-19T00:10:06Z"}, {"author": "Dennis Jackson", "text": "This kind of work is also quite domain specific. I'm doubtful a general group would work. Better to have independent panels if things go that way
", "time": "2024-03-19T00:10:51Z"}, {"author": "Quynh Dang", "text": "FFDHE 8192 to be precise.
", "time": "2024-03-19T00:11:02Z"}, {"author": "John Gray", "text": "So independent panels for each working group that needs it? I can imagine this model could work for LAMPS as well. For example, we are begging for people to look over our CMPv3 spec, so a similar model for that group would be most helpful. I guess this model could start here, and if it grows to work with other groups then great!
", "time": "2024-03-19T00:13:29Z"}, {"author": "Eric Rescorla", "text": "I actually do want the work to stop in that case.,
", "time": "2024-03-19T00:14:52Z"}, {"author": "Jonathan Hoyland", "text": "I do think we could leverage UFMRG to maybe coordinate this kind of activity
", "time": "2024-03-19T00:15:13Z"}, {"author": "Jonathan Hoyland", "text": "Also, thinking on it, if the IETF is formally blocked on the analysis (even if it doesn't find anything) then maybe you could leverage that to get published, i.e. the impact of the paper that it allows a protocol to advance.
", "time": "2024-03-19T00:16:10Z"}, {"author": "David Schinazi", "text": "+1 to what Stephen is saying. If the WG has consensus to require analysis for a specific doc that's fine. But we shouldn't have a blanket requirement
", "time": "2024-03-19T00:18:36Z"}, {"author": "David Schinazi", "text": "But it sounds like that matches what Deirdre is proposing
", "time": "2024-03-19T00:18:59Z"}, {"author": "Jonathan Hoyland", "text": "The WG or the chairs specifically?
", "time": "2024-03-19T00:19:01Z"}, {"author": "Jonathan Hoyland", "text": "I think the decision should be on the chairs taking input from the WG.
", "time": "2024-03-19T00:19:46Z"}, {"author": "David Schinazi", "text": "Oh absolutely not, that would be overreach by the chairs
", "time": "2024-03-19T00:20:01Z"}, {"author": "Dennis Jackson", "text": "Chairs shouldn't take decisions, just handle process.
", "time": "2024-03-19T00:20:05Z"}, {"author": "Eric Rescorla", "text": "Yah it has to be a WG decision. But the WG should decide to require analysis :)
", "time": "2024-03-19T00:20:20Z"}, {"author": "David Schinazi", "text": "If the WG reaches consensus then everything is possible :-)
", "time": "2024-03-19T00:20:43Z"}, {"author": "Eric Rescorla", "text": "getting a lot of noise from Patton
", "time": "2024-03-19T00:22:17Z"}, {"author": "Sean Turner", "text": "we are too
", "time": "2024-03-19T00:22:27Z"}, {"author": "Martin Thomson", "text": "MIC HOT
", "time": "2024-03-19T00:22:32Z"}, {"author": "Martin Thomson", "text": "SURFACE OF THE SUN
", "time": "2024-03-19T00:22:47Z"}, {"author": "Christopher Patton", "text": "Sorry, gang!
", "time": "2024-03-19T00:23:33Z"}, {"author": "Martin Thomson", "text": "Why not define a record size scaling extension?
", "time": "2024-03-19T00:25:05Z"}, {"author": "Martin Thomson", "text": "There could be a number, x, which is applied by shifting the record size left by x.
", "time": "2024-03-19T00:25:50Z"}, {"author": "Eric Rescorla", "text": "Well, we should decide if it's a good idea and then how to spell it.
", "time": "2024-03-19T00:26:07Z"}, {"author": "Martin Thomson", "text": "Then, you can have 2^32 bytes in each record.
", "time": "2024-03-19T00:26:14Z"}, {"author": "Michael T\u00fcxen", "text": "Is that OK from a crypto persepctive?
", "time": "2024-03-19T00:26:33Z"}, {"author": "Martin Thomson", "text": "Agreement? Evidence?
", "time": "2024-03-19T00:26:37Z"}, {"author": "Michael T\u00fcxen", "text": "Agreement
", "time": "2024-03-19T00:27:03Z"}, {"author": "Martin Thomson", "text": "Michael, you have to change usage limits, but I believe that most AEADs we use can have 2^36 bytes.
", "time": "2024-03-19T00:27:11Z"}, {"author": "Christopher Patton", "text": "What are the use cases?
", "time": "2024-03-19T00:27:18Z"}, {"author": "Martin Thomson", "text": "Agreement is no where near as good as evidence.
", "time": "2024-03-19T00:27:27Z"}, {"author": "Michael T\u00fcxen", "text": "One of the use cases would be signalling traffic based on a request from 3GPP.
", "time": "2024-03-19T00:27:48Z"}, {"author": "Michael T\u00fcxen", "text": "Using, for example, DTLS over SCTP.
", "time": "2024-03-19T00:28:05Z"}, {"author": "Michael T\u00fcxen", "text": "SCTP can handle such large messages.
", "time": "2024-03-19T00:28:13Z"}, {"author": "Martin Thomson", "text": "So... throughput over latency.
", "time": "2024-03-19T00:28:22Z"}, {"author": "Yoav Nir", "text": "Why staple an OCSP response when you can staple a multi-MB CRL
", "time": "2024-03-19T00:28:31Z"}, {"author": "David Benjamin", "text": "Martin Thomson said:
\n\n\nMichael, you have to change usage limits, but I believe that most AEADs we use can have 2^36 bytes.
\n
Realistically, since you have to buffer up the whole record before decrypting it (do not release unauthenticated plaintext to the application!), the record sizes will become impractical well before we get close to that.
", "time": "2024-03-19T00:29:26Z"}, {"author": "Stephen Farrell", "text": "wondering could this have any effect on traffic analysis?
", "time": "2024-03-19T00:30:00Z"}, {"author": "Martin Thomson", "text": "traffic analysis might be harder if things are more coalesced
", "time": "2024-03-19T00:30:58Z"}, {"author": "Martin Thomson", "text": "but only might
", "time": "2024-03-19T00:31:08Z"}, {"author": "Stephen Farrell", "text": "or easier if the sizes are more tied to application layer
", "time": "2024-03-19T00:31:19Z"}, {"author": "Dennis Jackson", "text": "There are good-ish solutions for traffic analysis, we should standardise one sometime :-)
", "time": "2024-03-19T00:31:35Z"}, {"author": "Stephen Farrell", "text": "@dennis yeah that'd be good, who's interested?
", "time": "2024-03-19T00:33:34Z"}, {"author": "David Benjamin", "text": "Concretely, the overhead of one TLS 1.3 AES-GCM record is 5 + 16 + 1 = 22 bytes. 22 / 16K is 0.14% overhead. We get to divide that by 4, but it's already pretty small.
", "time": "2024-03-19T00:34:36Z"}, {"author": "Martin Thomson", "text": "I doubt that the limiting factor is the tag overhead
", "time": "2024-03-19T00:36:07Z"}, {"author": "Rich Salz", "text": "Scaling the record size is definitely a neat hack, with emphasis on both words.
", "time": "2024-03-19T00:36:31Z"}, {"author": "Eric Rescorla", "text": "+1
", "time": "2024-03-19T00:36:45Z"}, {"author": "Eric Rescorla", "text": "Shall we send this draft to the triage panel?
", "time": "2024-03-19T00:37:19Z"}, {"author": "Eric Rescorla", "text": "Mattsson's
", "time": "2024-03-19T00:37:30Z"}, {"author": "Martin Thomson", "text": "Mattsson's should go to triage. There are some non-obvious gotchas.
", "time": "2024-03-19T00:37:57Z"}, {"author": "Martin Thomson", "text": "But we should try to get a little more concrete on the solution part first.
", "time": "2024-03-19T00:38:08Z"}, {"author": "Deirdre Connolly", "text": ":gopher: \u27f0
", "time": "2024-03-19T00:39:20Z"}, {"author": "Christopher Patton", "text": "I am an enthusiastic supporter of this draft, but slightly biased (I work with Jonathan)
", "time": "2024-03-19T00:41:14Z"}, {"author": "Dennis Jackson", "text": "Stephen Farrell said:
\n\n\n@dennis yeah that'd be good, who's interested?
\n
I think its a logical next step once ECH is thriving in the wild. Probably need to think a bit about the layer though. Likely going to need some work at both the HTTP and TLS layers.
", "time": "2024-03-19T00:41:17Z"}, {"author": "David Schinazi", "text": "Is there a formal proof for this one?
", "time": "2024-03-19T00:41:20Z"}, {"author": "Jonathan Hoyland", "text": "The code is available at https://github.com/jhoyla/tlsflags
", "time": "2024-03-19T00:41:44Z"}, {"author": "Jonathan Hoyland", "text": "So because it's a hint, I assert it doesn't need a formal proof, and there's no triage panel to gainsay me :joy:
", "time": "2024-03-19T00:42:23Z"}, {"author": "David Benjamin", "text": "An exported-authenticator-like design seems kind of overkill here.
", "time": "2024-03-19T00:44:38Z"}, {"author": "Jonathan Hoyland", "text": "Technically the payload can be exchanged over _any_ channel, even publicly, without compromising the _auth_ guarantees.
", "time": "2024-03-19T00:46:13Z"}, {"author": "Eric Rescorla", "text": "Not with that attitude
", "time": "2024-03-19T00:47:09Z"}, {"author": "Jonathan Hoyland", "text": "The more awkward case is what happens when a new session ticket and key update cross in mid-flight
", "time": "2024-03-19T00:48:41Z"}, {"author": "David Benjamin", "text": "I don't believe this impacts the resumption secret.
", "time": "2024-03-19T00:49:06Z"}, {"author": "Martin Thomson", "text": "My understanding is that this does not interact with resumption
", "time": "2024-03-19T00:49:17Z"}, {"author": "Jonathan Hoyland", "text": "It doesn't that's my point.
", "time": "2024-03-19T00:49:19Z"}, {"author": "Sean Turner", "text": "going to close the queue in a couple of minutes.
", "time": "2024-03-19T00:49:33Z"}, {"author": "Martin Thomson", "text": "So that brings the whole thing into question.
", "time": "2024-03-19T00:49:35Z"}, {"author": "Jonathan Hoyland", "text": "So the state of the TLS session is ambiguous to the server
", "time": "2024-03-19T00:49:37Z"}, {"author": "David Benjamin", "text": "But yes there are a lot of things crossing mid-flight issues with the original draft. But the solution is worse than the problem. We should have just fixed the problem. :-)
", "time": "2024-03-19T00:49:44Z"}, {"author": "David Benjamin", "text": "Jonathan Hoyland said:
\n\n\nSo the state of the TLS session is ambiguous to the server
\n
It's not ambiguous because it doesn't impact the resumption secret. The ticket state is unambiguously the original resumption secret.
", "time": "2024-03-19T00:50:20Z"}, {"author": "David Benjamin", "text": "I think there's a pretty straightforward design with three messages instead of two, that avoids all these problems.
", "time": "2024-03-19T00:51:05Z"}, {"author": "Jonathan Hoyland", "text": "David Benjamin said:
\n\n\nJonathan Hoyland said:
\n\n\nSo the state of the TLS session is ambiguous to the server
\nIt's not ambiguous because it doesn't impact the resumption secret. The ticket state is unambiguously the original resumption secret.
\n
So the DH-KEM is (effectively) an authentication protocol, and in effect the server doesn't know whether the client has successfully authed or not when the resumption happens.
", "time": "2024-03-19T00:51:37Z"}, {"author": "Martin Thomson", "text": "The three message option described by Ilari is an example that works..
", "time": "2024-03-19T00:52:41Z"}, {"author": "Martin Thomson", "text": "It's not ideal, but I think that it managed glare well enough.
", "time": "2024-03-19T00:52:57Z"}, {"author": "Sean Turner", "text": "we have locked the queu
", "time": "2024-03-19T00:53:16Z"}, {"author": "David Benjamin", "text": "It only matters as an authentication protocol if you actually use it as one. If you're just generating an ephemeral key to swizzle into the traffic secret, it doesn't impact the resumption state.
", "time": "2024-03-19T00:57:17Z"}, {"author": "Dennis Jackson", "text": "This is the current draft text:
\nTo perform public key encryption the sender needs to have access to the public key of the recipient. This document makes the assumption that the public key in the exchanged end-entity certificate can be used with the HPKE KEM. The use of HPKE, and the recipients long-term public key, in the ephemeral-static Diffie-Hellman exchange provides perfect forward secrecy of the ongoing connection and demonstrates possession of the long-term secret key.
", "time": "2024-03-19T00:57:35Z"}, {"author": "David Benjamin", "text": "Wait, I'm confused... it's using the signing key in the certificate as a KEM key?
", "time": "2024-03-19T00:58:07Z"}, {"author": "Martin Thomson", "text": "wat
", "time": "2024-03-19T00:58:16Z"}, {"author": "Dennis Jackson", "text": "That's what the draft says, but that's not what Hannes is saying as I understand them
", "time": "2024-03-19T00:58:22Z"}, {"author": "John Preu\u00df Mattsson", "text": "I think updating the exporter secret is a requirement
", "time": "2024-03-19T01:00:52Z"}, {"author": "David Benjamin", "text": "We cannot have both. Either we leave exporter secret alone and have transparent rekeying (i.e. application protocol is not aware of when this happens), or we sacrifice transparent rekeying and update the exporter secret.
", "time": "2024-03-19T01:01:56Z"}, {"author": "John Preu\u00df Mattsson", "text": "I don't think it need to be transparant to the application layer. The application layer can trigger a key update at the TLS layer
", "time": "2024-03-19T01:04:21Z"}, {"author": "Deirdre Connolly", "text": "tlswg :point_right: :point_left: tlswg
\nDamm TLS WG, they ruined TLS.
", "time": "2024-03-19T01:04:56Z"}, {"author": "Eric Rescorla", "text": "are we just doing memes now?
", "time": "2024-03-19T01:05:09Z"}, {"author": "Deirdre Connolly", "text": "/i'm/ just doing memes now
", "time": "2024-03-19T01:05:32Z"}, {"author": "Deirdre Connolly", "text": "I can't reactji in MeetEcho :sob:
", "time": "2024-03-19T01:05:49Z"}, {"author": "Jonathan Hoyland", "text": "That's one reason why EAs can work here. Because they can be transmitted + negotiated out of bound, so if you can inject the agreed secrets into the master secret you don't need the application (per se) to be in the loop.
", "time": "2024-03-19T01:06:03Z"}, {"author": "John Preu\u00df Mattsson", "text": "Yes please, more memes :)
", "time": "2024-03-19T01:06:15Z"}, {"author": "Eric Rescorla", "text": "Argh. do I have to use zulip to send memes? The Meetecho client doesn't seem to know how
", "time": "2024-03-19T01:06:36Z"}, {"author": "Dennis Jackson", "text": "Yes
", "time": "2024-03-19T01:06:45Z"}, {"author": "Deirdre Connolly", "text": "I just posted a link to an image
", "time": "2024-03-19T01:06:50Z"}, {"author": "Deirdre Connolly", "text": "oh man MeetEcho doesn't load those? alas
", "time": "2024-03-19T01:07:02Z"}, {"author": "Eric Rescorla", "text": "", "time": "2024-03-19T01:07:08Z"}, {"author": "John Preu\u00df Mattsson", "text": "EKR wrote:
\n\n\nThe Meetecho client doesn't seem to know how
\n
File an issue, this is a serious problem
", "time": "2024-03-19T01:07:22Z"}, {"author": "Christopher Patton", "text": "AND MY AXE
", "time": "2024-03-19T01:07:31Z"}, {"author": "Eric Rescorla", "text": "", "time": "2024-03-19T01:08:01Z"}, {"author": "Eric Rescorla", "text": "argh. even so
", "time": "2024-03-19T01:08:14Z"}, {"author": "Deirdre Connolly", "text": "oooooo :fire:
", "time": "2024-03-19T01:08:17Z"}, {"author": "Eric Rescorla", "text": "\n![](\"/user_uploads/2/1a/Jp2ao-fy8yC_NbJkYJncooef/image.png\")
FINALY
", "time": "2024-03-19T01:08:35Z"}, {"author": "David Benjamin", "text": "3-message design:
\nMaybe the right answer here is \"sure, you can have a codepoint, but not an RFC\"
", "time": "2024-03-19T01:10:07Z"}, {"author": "Eric Rescorla", "text": "That's my proposal
", "time": "2024-03-19T01:10:16Z"}, {"author": "Stephen Farrell", "text": "wouldn't the world be better without even the codepoint though?
", "time": "2024-03-19T01:10:32Z"}, {"author": "David Benjamin", "text": "At any point in this process, app data can freely flow. If both sides act as initiator at the same time, you just have two of those flows happen independently and concurrently without any fuss.
", "time": "2024-03-19T01:10:39Z"}, {"author": "Christian Huitema", "text": "decades of Internet, and yet these damn connections are breaking...
", "time": "2024-03-19T01:10:44Z"}, {"author": "Eric Rescorla", "text": "Well our policies just allow the code point
", "time": "2024-03-19T01:10:45Z"}, {"author": "Martin Thomson", "text": "David's EKU design seems reasonable on the face of it.
", "time": "2024-03-19T01:10:45Z"}, {"author": "Dennis Jackson", "text": "Fairly similar to 00 of the draft
", "time": "2024-03-19T01:10:57Z"}, {"author": "Stephen Farrell", "text": "our policies do allow the codepoint sure, but that doesn't make it a good idea
", "time": "2024-03-19T01:11:09Z"}, {"author": "Martin Thomson", "text": "The TLS working group should not publish this document (or anything like it) at this time.
", "time": "2024-03-19T01:11:14Z"}, {"author": "Jonathan Hoyland", "text": "Ok, so can I propose something that's total madness, but just to demonstrate the shape.
\nImagine you have a piece of code _adjacent_ to the TLS stack (in the TLS library) that negotiates an EA style thing (which is kosher because the EA style things _can be negotiated out-of-band) and inject that into the master secret. It's totally independent of the application layer, but it doesn't change the TLS state machine and it doesn't invalidate the proofs.
Dennis Jackson said:
\n\n\nFairly similar to 00 of the draft
\n
00 didn't have the third message and updated the initiator's write secret at step 2. That has a synchronization problem, but easily fixed with the third message.
", "time": "2024-03-19T01:11:33Z"}, {"author": "Jonathan Hoyland", "text": "It operates by sending messages to Twitter.
", "time": "2024-03-19T01:11:53Z"}, {"author": "Martin Thomson", "text": "the 00 draft also had unidirectional updates, whereas david is suggesting both directions update
", "time": "2024-03-19T01:12:02Z"}, {"author": "Jonathan Hoyland", "text": "Once the Twitter-negotiation protocol is complete, you can update the keys.
", "time": "2024-03-19T01:12:28Z"}, {"author": "Martin Thomson", "text": "code point suggestion: 0xbad1
", "time": "2024-03-19T01:12:44Z"}, {"author": "David Benjamin", "text": "(Synchronization problem = if you update your write secret on receipt of something, the other side has no idea where in the stream you received their message. And so you have shut off app data and lock things up. Once you do that, it cannot be a transparent mechanism anymore.)
", "time": "2024-03-19T01:12:59Z"}, {"author": "Martin Thomson", "text": "or the classic: 0xc0de
", "time": "2024-03-19T01:13:10Z"}, {"author": "Thom Wiggers", "text": "@Jonathan Hoyland :cross_mark:
", "time": "2024-03-19T01:13:20Z"}, {"author": "Thom Wiggers", "text": "(see what I did there)
", "time": "2024-03-19T01:13:26Z"}, {"author": "Richard Barnes", "text": ":sun_face::rainbow::unicorn:
", "time": "2024-03-19T01:14:31Z"}, {"author": "Martin Thomson", "text": "David in TLS, you need a message. In DTLS, you don't.
", "time": "2024-03-19T01:14:37Z"}, {"author": "Jonathan Hoyland", "text": "@Thom Wiggers Do you disagree with my security analysis, or is the protocol just too gruesome :joy: ?
", "time": "2024-03-19T01:14:45Z"}, {"author": "David Benjamin", "text": "Martin Thomson said:
\n\n\nDavid in TLS, you need a message. In DTLS, you don't.
\n
Hehe, I could believe that. Haven't paged in KeyUpdate in DTLS 1.3. :-)
", "time": "2024-03-19T01:15:19Z"}, {"author": "Thom Wiggers", "text": "I mainly disagree that they changed the name of twitter to X
", "time": "2024-03-19T01:15:31Z"}, {"author": "Martin Thomson", "text": "It's Xitter
", "time": "2024-03-19T01:15:45Z"}, {"author": "Eric Rescorla", "text": "\n![](\"/user_uploads/2/6e/TWC8wElDYf95xEorJdFanKfG/image.png\")
:poop:
", "time": "2024-03-19T01:15:46Z"}, {"author": "Martin Thomson", "text": "The X is pronounced \"SH\"
", "time": "2024-03-19T01:16:06Z"}, {"author": "John Gray", "text": "+1 Eric :)
", "time": "2024-03-19T01:16:22Z"}, {"author": "Jonathan Hoyland", "text": "lol, those timescales hurt me
", "time": "2024-03-19T01:17:02Z"}, {"author": "Ira McDonald", "text": "German BSI has published an updated version of Technical Guideline TR-02102-1 \"Cryptographic Algorithms and Key Lengths\" (14 March 2024) https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr02102/tr02102_node.html - which still calls for only Hybrid Classical/PQ algorithms
", "time": "2024-03-19T01:18:04Z"}, {"author": "Eric Rescorla", "text": "LAMPS is doing pure PQ
", "time": "2024-03-19T01:18:49Z"}, {"author": "Stephen Farrell", "text": "there's a lamps proposal for everything isn't there?
", "time": "2024-03-19T01:19:03Z"}, {"author": "Martin Thomson", "text": "pure PQ for signatures is probably fine
", "time": "2024-03-19T01:19:06Z"}, {"author": "Dennis Jackson", "text": "\n", "time": "2024-03-19T01:19:15Z"}, {"author": "Eric Rescorla", "text": "Even though hybrid solutions may be allowed or required due to protocol standards, product availability, or interoperability requirements, CNSA 2.0 algorithms will become mandatory to select at the given date, and selecting CNSA 1.0 algorithms alone will no longer be approved
\n
Pure hashes.
", "time": "2024-03-19T01:19:16Z"}, {"author": "Eric Rescorla", "text": "Intergalactic kerberos
", "time": "2024-03-19T01:19:29Z"}, {"author": "Dennis Jackson", "text": "This was also in the CNSA Announcement, hybrid forever?
", "time": "2024-03-19T01:19:40Z"}, {"author": "Eric Rescorla", "text": "I actually don't understand what that says
", "time": "2024-03-19T01:20:04Z"}, {"author": "Dennis Jackson", "text": "Me neither, but I'm claiming it can be read however you like
", "time": "2024-03-19T01:20:20Z"}, {"author": "Stephen Farrell", "text": "let the market decide and end up with hundreds of suites, that worked well for tls1.2
", "time": "2024-03-19T01:20:29Z"}, {"author": "Martin Thomson", "text": "It's a pretty good chimera
", "time": "2024-03-19T01:20:36Z"}, {"author": "David Benjamin", "text": "I read that to mean that they don't particular care between hybrid vs non-hybrid. They just want to make sure their thing is among the inputs to the protocol.
", "time": "2024-03-19T01:21:34Z"}, {"author": "Martin Thomson", "text": "Less reasonable people will reach less reasonable conclusions, David
", "time": "2024-03-19T01:22:51Z"}, {"author": "Dennis Jackson", "text": "Its worth noting that CNSA also requires their solutions to have two independent layers.
", "time": "2024-03-19T01:23:54Z"}, {"author": "Thom Wiggers", "text": "would these non-hybrid code points not just get registered anyway?
", "time": "2024-03-19T01:24:06Z"}, {"author": "Thom Wiggers", "text": "I mean brainpool is also registered
", "time": "2024-03-19T01:24:18Z"}, {"author": "Deirdre Connolly", "text": "image.png
\nfrom https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
![](\"/user_uploads/2/1f/MldIQmGP26Pl7r1H9D3fNfpf/image.png\")
so we should define rot13 codepoints as well?
", "time": "2024-03-19T01:25:57Z"}, {"author": "Eric Rescorla", "text": "rot-39
", "time": "2024-03-19T01:26:06Z"}, {"author": "Jonathan Hoyland", "text": "Isn't this what \"experimental\" status is designed to be?
", "time": "2024-03-19T01:26:24Z"}, {"author": "Rich Salz", "text": "Would \"just get a codepoint\" work, since it requires more than just a codepoint based on the slide that injects new things?
", "time": "2024-03-19T01:26:27Z"}, {"author": "Yoav Nir", "text": "3-rot13
", "time": "2024-03-19T01:26:35Z"}, {"author": "Christopher Patton", "text": "\"The clock doesn't start when the RFC is published: the clock starts when people start caring.\" David Schinazi, Enthusiast
", "time": "2024-03-19T01:27:27Z"}, {"author": "Christopher Patton", "text": "Wisdom.
", "time": "2024-03-19T01:27:41Z"}, {"author": "Dan Harkins", "text": "I profoundly disagree with Stephen and Martin. This is clean and good. It's noore risk than using a curve that someone in the future might find weak.
", "time": "2024-03-19T01:27:44Z"}]