[{"author": "Carrick", "text": "

Hi!

", "time": "2022-07-25T19:00:30Z"}, {"author": "Richard Barnes", "text": "

aloha

", "time": "2022-07-25T19:01:00Z"}, {"author": "Christopher Patton", "text": "

wait I don't have audio

", "time": "2022-07-25T19:02:17Z"}, {"author": "Christopher Patton", "text": "

have we started?

", "time": "2022-07-25T19:02:22Z"}, {"author": "Jonathan Hoyland", "text": "

Yes

", "time": "2022-07-25T19:02:29Z"}, {"author": "Jonathan Lennox", "text": "

Chairs are talking

", "time": "2022-07-25T19:02:30Z"}, {"author": "Jonathan Hoyland", "text": "

Currently bashing the agenda

", "time": "2022-07-25T19:02:38Z"}, {"author": "Sofia Celi", "text": "

wooh!!

", "time": "2022-07-25T19:03:05Z"}, {"author": "Jonathan Hoyland", "text": "

:partying_face:

", "time": "2022-07-25T19:03:07Z"}, {"author": "Jonathan Hoyland", "text": "

DC test vectors are incoming

", "time": "2022-07-25T19:03:43Z"}, {"author": "Christopher Patton", "text": "

Sounds Noise-ish?

", "time": "2022-07-25T19:05:50Z"}, {"author": "Jessica Krynitsky", "text": "

Virtual audio is pretty choppy

", "time": "2022-07-25T19:06:50Z"}, {"author": "Carrick", "text": "

audio is ok for me

", "time": "2022-07-25T19:07:08Z"}, {"author": "Jonathan Hoyland", "text": "

Sounds smooth to me

", "time": "2022-07-25T19:07:10Z"}, {"author": "Richard Barnes", "text": "

ok for me too

", "time": "2022-07-25T19:07:18Z"}, {"author": "Clint Wilson", "text": "

Good for me as well

", "time": "2022-07-25T19:07:23Z"}, {"author": "Sofia Celi", "text": "

sounds good for me

", "time": "2022-07-25T19:07:37Z"}, {"author": "Penglin Yang", "text": "

but the speaker is out of camera?

", "time": "2022-07-25T19:08:48Z"}, {"author": "Carrick", "text": "

yeah :(

", "time": "2022-07-25T19:08:59Z"}, {"author": "Richard Barnes", "text": "

MeetEcho: Could we rotate the camera to see Ben?

", "time": "2022-07-25T19:09:04Z"}, {"author": "Thom Wiggers", "text": "

very emotive hands though

", "time": "2022-07-25T19:09:09Z"}, {"author": "Carrick", "text": "

haha

", "time": "2022-07-25T19:09:15Z"}, {"author": "Penglin Yang", "text": "

:grin:

", "time": "2022-07-25T19:09:25Z"}, {"author": "Carrick", "text": "

thanks!

", "time": "2022-07-25T19:09:29Z"}, {"author": "Jonathan Hoyland", "text": "

Eerie. It's almost like they're listening to us.

", "time": "2022-07-25T19:09:47Z"}, {"author": "Richard Barnes", "text": "

y u no cbor

", "time": "2022-07-25T19:09:51Z"}, {"author": "Christian Huitema", "text": "

save a few bytes... and PQ?

", "time": "2022-07-25T19:10:42Z"}, {"author": "Jonathan Hoyland", "text": "

W.r.t. \"Can we omit empty messages\" having just experienced the joy of playing with certificates that omit the hash parameters with a parser that requires ASN.1 NULL parameters, can we please not.

", "time": "2022-07-25T19:12:10Z"}, {"author": "Martin Thomson", "text": "

@Stephen Farrell it might be possible to create an ambiguous encoding by defining a \"tweak\" that is poor

", "time": "2022-07-25T19:17:16Z"}, {"author": "Christopher Patton", "text": "

+1 Jonathan

", "time": "2022-07-25T19:18:27Z"}, {"author": "Martin Thomson", "text": "

In addition to the point ekr made, which is that composition of tweaks might result in an insecure whole, there is the work that ADL did on QUIC. There, the encoding was structured in a way that was ambiguous, such that the same sequence of bytes could be interpreted multiple ways. Nothing in this design inherently prevents the creation of ambiguous encodings (see also unique particle attribution), which is fine, but it means that each tweak needs to be very carefully defined

", "time": "2022-07-25T19:20:24Z"}, {"author": "Martin Thomson", "text": "

I'm concerned that that means we need analysis of each, both independently and jointly.

", "time": "2022-07-25T19:20:51Z"}, {"author": "Jonathan Lennox", "text": "

Does that mean that the FCFS registrations are a bad idea?

", "time": "2022-07-25T19:21:02Z"}, {"author": "Benjamin Kaduk", "text": "

Are the encodings still ambiguous with the template prepended to the transcript as a synthetic message?

", "time": "2022-07-25T19:21:47Z"}, {"author": "Jonathan Hoyland", "text": "

@MT Surely permitting ambiguous encodings is a terrible plan?

", "time": "2022-07-25T19:21:58Z"}, {"author": "Jonathan Hoyland", "text": "

It's just begging for a channel synchronisation attack

", "time": "2022-07-25T19:22:22Z"}, {"author": "Christopher Patton", "text": "

Does the well-known endpoint need to specify the port(s) that support ECH? Could this be made optional?

", "time": "2022-07-25T19:23:05Z"}, {"author": "Martin Thomson", "text": "

@Jonathan Hoyland I didn't design this protocol, but it seems like you could do ambiguous encodings.

", "time": "2022-07-25T19:23:21Z"}, {"author": "Martin Thomson", "text": "

We probably won't though.

", "time": "2022-07-25T19:23:27Z"}, {"author": "Martin Thomson", "text": "

I do think that @Jonathan Lennox is right about FCFS though.

", "time": "2022-07-25T19:23:48Z"}, {"author": "Thom Wiggers", "text": "

is the prepended template fixed-length?

", "time": "2022-07-25T19:23:56Z"}, {"author": "Jonathan Hoyland", "text": "

Is there a way to (cryptographically) enforce non-ambiguity?

", "time": "2022-07-25T19:24:03Z"}, {"author": "Benjamin Kaduk", "text": "

I'm pretty sure the port-prefixed QNAME vs \"port=\" in the record relate to the incoming vs outgoing port

", "time": "2022-07-25T19:26:48Z"}, {"author": "Christopher Patton", "text": "

ohhhhh

", "time": "2022-07-25T19:28:19Z"}, {"author": "Christopher Patton", "text": "

Thanks for the clarification Ben

", "time": "2022-07-25T19:28:25Z"}, {"author": "Christian Huitema", "text": "

Fetching the DNS record can be observed. There is privacy value in doing ECH without having to hit the DNS firt.

", "time": "2022-07-25T19:29:06Z"}, {"author": "Christian Huitema", "text": "

Why is this better than doing DoH through the HTTP server?

", "time": "2022-07-25T19:30:59Z"}, {"author": "Christopher Patton", "text": "

If I were deploying this, I think I'd want to have TLS client auth for the endpoint

", "time": "2022-07-25T19:32:59Z"}, {"author": "Ted Hardie", "text": "

@Christopher I think that makes a lot of sense.

", "time": "2022-07-25T19:33:42Z"}, {"author": "Benjamin Kaduk", "text": "

TLS ExtensionType Value 53 was an early allocation and we had to allocate 54 when we changed the wire protocol.

", "time": "2022-07-25T19:37:00Z"}, {"author": "Benjamin Kaduk", "text": "

Wait, why isn't RSA marked as 'N'?
\n<ducks>

", "time": "2022-07-25T19:38:03Z"}, {"author": "Martin Thomson", "text": "

RSA should be D

", "time": "2022-07-25T19:38:40Z"}, {"author": "Martin Thomson", "text": "

anonymous should be D

", "time": "2022-07-25T19:38:54Z"}, {"author": "Benjamin Kaduk", "text": "

Wait, is that Viktor on site?!

", "time": "2022-07-25T19:39:16Z"}, {"author": "David Benjamin", "text": "

Do anonymous and none even appear on the wire?

", "time": "2022-07-25T19:40:12Z"}, {"author": "Jabber", "text": "

sftcd: @kaduk: it is viktor here

", "time": "2022-07-25T19:40:18Z"}, {"author": "Christopher Patton", "text": "

SHA-224 is just truncated SHA-256.

", "time": "2022-07-25T19:40:21Z"}, {"author": "David Benjamin", "text": "

(Truncated and with different initial state.)

", "time": "2022-07-25T19:41:18Z"}, {"author": "Christopher Patton", "text": "

+1 SHA-224 = N

", "time": "2022-07-25T19:41:27Z"}, {"author": "Christopher Patton", "text": "

(Thanks David!)

", "time": "2022-07-25T19:41:38Z"}, {"author": "Martin Thomson", "text": "

Nothing wrong with SHA-224, at least not as far as I'm aware

", "time": "2022-07-25T19:41:47Z"}, {"author": "Benjamin Kaduk", "text": "

sftcd: oh cool! More reasons for me to be sad I'm not there in person, I guess.

", "time": "2022-07-25T19:42:04Z"}, {"author": "David Benjamin", "text": "

For more reasons why not to allow explicit curves, see CVE-2022-0778.

", "time": "2022-07-25T19:44:17Z"}, {"author": "Martin Thomson", "text": "

Yes, explicit curves are concretely bad news. Uncompressed curves just makes software go wonky.

", "time": "2022-07-25T19:44:48Z"}, {"author": "Martin Thomson", "text": "

Either way, D

", "time": "2022-07-25T19:44:53Z"}, {"author": "Benjamin Kaduk", "text": "

uncompressed or compressed?

", "time": "2022-07-25T19:45:26Z"}, {"author": "Martin Thomson", "text": "

Benjamin Kaduk said:

\n
\n

uncompressed or compressed?

\n
\n

oops: compressed

", "time": "2022-07-25T19:47:35Z"}, {"author": "Sean Turner", "text": "

For 224, I was going for anything less that 256. But, we make it Y.

", "time": "2022-07-25T19:47:39Z"}, {"author": "Martin Thomson", "text": "

This idea of safelisting extra FFDHE groups is not a great idea in my opinion. We did RFC 7919.

", "time": "2022-07-25T19:48:17Z"}, {"author": "Martin Thomson", "text": "

@Uri Blumenthal can you write your comment somewhere? I didn't get that.

", "time": "2022-07-25T19:48:57Z"}, {"author": "Christopher Wood", "text": "

@Uri could you please repeat your comment here?

", "time": "2022-07-25T19:49:04Z"}, {"author": "Jonathan Hoyland", "text": "

Can you elaborate on what you mean by the logic added by PQ algorithms too please.

", "time": "2022-07-25T19:49:34Z"}, {"author": "Jonathan Hoyland", "text": "

I didn't catch what you were implying

", "time": "2022-07-25T19:49:50Z"}, {"author": "David Benjamin", "text": "

Yeah, the pre-7919 DHE construction in TLS is just a disaster. I would strongly support just abandoning it at this point.

", "time": "2022-07-25T19:50:33Z"}, {"author": "Martin Thomson", "text": "

Yeah. 7919 didn't work. I implemented a rule to only allow 7919 groups, but it is not possible to deploy that.

", "time": "2022-07-25T19:51:43Z"}, {"author": "Uri Blumenthal", "text": "

I think that this draft is unnecessarily strict, from both deployment and security points of view. Examples of stuff that should be retained: RSA, FFDHE. PQ implications: all the NIST PQC winners and finalists are KEMs, not KA - aka, similar to RSA rather than DH (yes, I'm aware of the differences between RSA-based and, e.g., Kyber-based KEM).

", "time": "2022-07-25T19:52:15Z"}, {"author": "Roy Williams", "text": "

I suggest be careful when dropping SHA1 as it is integral to GITs hashing (yes it does a bit more). Wording should carefully crafted.

", "time": "2022-07-25T19:53:59Z"}, {"author": "David Benjamin", "text": "

Martin: Yup. We just removed DHE in Chrome because it's unsalvageable. For 7919 to work, we'd have needed to give them different cipher suites.

", "time": "2022-07-25T19:54:06Z"}, {"author": "Martin Thomson", "text": "

In practice, we can use FFDHE in TLS 1.3, but not in TLS 1.2, at least not safely.

", "time": "2022-07-25T19:54:32Z"}, {"author": "Jabber", "text": "

sftcd: dkg's comment seems reasonable (as always) but out of scope of tls given groups are used in other protocols too so I'd guess pentesters would have the same reactions to 'em once they see 'em

", "time": "2022-07-25T19:54:58Z"}, {"author": "David Benjamin", "text": "

Uri: I do not believe there is an impact of this draft on PQ. The draft does not remove use of KEMs.

", "time": "2022-07-25T19:55:11Z"}, {"author": "David Benjamin", "text": "

https://mailarchive.ietf.org/arch/msg/tls/zPVfG2ese-R0SY9hRjGrbzoBqqM/

", "time": "2022-07-25T19:55:24Z"}, {"author": "Christopher Wood", "text": "

+1 David

", "time": "2022-07-25T19:56:26Z"}, {"author": "Jonathan Hoyland", "text": "

I think the pen-testing comment disproves Uri

", "time": "2022-07-25T19:57:54Z"}, {"author": "Martin Thomson", "text": "

I think that @Mike Ounsworth 's example puts paid to @Uri Blumenthal 's last argument.

", "time": "2022-07-25T19:57:57Z"}, {"author": "Martin Thomson", "text": "

jinx @Jonathan Hoyland

", "time": "2022-07-25T19:58:02Z"}, {"author": "Thom Wiggers", "text": "

Maybe the logjam paper finally reached the pentesting folks

", "time": "2022-07-25T19:58:18Z"}, {"author": "Martin Thomson", "text": "

the wheels turn slowly

", "time": "2022-07-25T19:58:33Z"}, {"author": "Thom Wiggers", "text": "

But they missed that the advice to generate your own DH params was for 1024 bit parameters for sofware that didn't support anything else

", "time": "2022-07-25T19:58:41Z"}, {"author": "David Benjamin", "text": "

(Incidentally, the deployability issue with 7919 is also documented in https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo/ and https://mailarchive.ietf.org/arch/msg/tls/DzazUXCUZDUpVgBPVHOwatb65dA/, if folks need pointers.)

", "time": "2022-07-25T19:58:57Z"}, {"author": "Uri Blumenthal", "text": "

@David, protocol logic of KEM is pretty similar to that of RSA Key Exchange (or, should I say, Key Encapsulation). Thus, removing RSA does not seem to make sense at this point. @Martin, I don't see that \"puts paid\"/

", "time": "2022-07-25T19:59:45Z"}, {"author": "Mike Ounsworth", "text": "

So here's an example of a \"finding\" by (I believe) Nexpose for a server supporting TLS 1.2 with 2048 DHE

\n
\n

The server is using a common or default prime number as a parameter during the Diffie-Hellman key exchange. This makes the secure session vulnerable to a precomputation attack. An attacker can spend a significant amount of time to generate a lookup/rainbow table for a particular prime number. This lookup table can then be used to obtain the shared secret for the handshake and decrypt the session.

\n
\n

Like, what do I do when I have a customer screaming at me to \"fix\" that?
\nThe best I came up with was to say \"I agree with the tool that this is a \"LOW\"\", but they still want me to fix it.

", "time": "2022-07-25T20:00:22Z"}, {"author": "Carrick", "text": "

@mike Turn off DHE?

", "time": "2022-07-25T20:01:11Z"}, {"author": "David Benjamin", "text": "

Uri: No, that's not right. You can use KEMs without forward secrecy, as in RSA key exchange, which would be undesirable for the same reasons as this draft. You can use KEMs as an ephemeral key exchange with a signing key for authentication, as in TLS 1.3. You can use KEMs as both an ephemeral key exchange and a separate instance for authentication, as in KEM-TLS.

", "time": "2022-07-25T20:01:58Z"}, {"author": "Uri Blumenthal", "text": "

@Mike, are you implying that it is not possible to implement secure DHE???

", "time": "2022-07-25T20:01:59Z"}, {"author": "Martin Thomson", "text": "

@Carrick is right. The other advantage of that is that your connection setup will go a lot faster.

", "time": "2022-07-25T20:02:16Z"}, {"author": "Martin Thomson", "text": "

Of course, turning off all key exchange methods will make it go even faster.

", "time": "2022-07-25T20:03:31Z"}, {"author": "Carrick", "text": "

hah

", "time": "2022-07-25T20:03:52Z"}, {"author": "Mike Ounsworth", "text": "

Uri Blumenthal said:

\n
\n

@Mike, are you implying that it is not possible to implement secure DHE???

\n
\n

No, the opposite in fact, I am implying (or asking I guess) that the pre-computation attack for a well-chosen DH 2048 group is (currently) intractable and should not be a security finding at all.

", "time": "2022-07-25T20:04:03Z"}, {"author": "Benjamin Kaduk", "text": "

@Uri Blumenthal the point is that there are a lot of people who are generating their own DHE parameters to fix the report, but who do not understand what they are doing. An assertion that people using custom FFDHE groups know what they are doing is proven false by this data.

", "time": "2022-07-25T20:04:39Z"}, {"author": "Uri Blumenthal", "text": "

@David, same approach that makes PQ KEM forward-secure, could be used with RSA. (I find it strange to find myself defending a \"pre-PQ\" :) algorithm...)

", "time": "2022-07-25T20:05:34Z"}, {"author": "Uri Blumenthal", "text": "

@Benjamin, OK, I hear you.

", "time": "2022-07-25T20:06:05Z"}, {"author": "Jonathan Hoyland", "text": "

Is this just about message formatting, or are you planning to send the messages over the Internet?

", "time": "2022-07-25T20:06:43Z"}, {"author": "David Benjamin", "text": "

Uri: You're right, it could. Except that RSA keygen is far too slow for this to be practical. But that's not what we did in TLS.

", "time": "2022-07-25T20:07:06Z"}, {"author": "David Benjamin", "text": "

The draft isn't about deprecating all possible constructions using the underlying primitives from all possible protocols. The draft is about deprecating particular constructions because those particular constructions have problems.

", "time": "2022-07-25T20:08:14Z"}, {"author": "Nimrod Aviram", "text": "

@David +1

", "time": "2022-07-25T20:08:31Z"}, {"author": "Benjamin Kaduk", "text": "

Could the chairs weigh in on what the WG is being asked to do w.r.t. the SCVP stuff? Is this a request for WG adoption?

", "time": "2022-07-25T20:09:44Z"}, {"author": "Jonathan Hoyland", "text": "

What is the client supposed to do when the status_request / OCSP fails / comes back rejected?

", "time": "2022-07-25T20:11:23Z"}, {"author": "Jonathan Hoyland", "text": "

Does the plane not land?

", "time": "2022-07-25T20:11:32Z"}, {"author": "Benjamin Kaduk", "text": "

I think I'm hearing that the aviation standards body is going to want an IETF standards-track RFC, in the conversation here.

", "time": "2022-07-25T20:11:56Z"}, {"author": "Benjamin Kaduk", "text": "

and thus that we are being asked to adopt as a WG document so as to make getting that proposed standard out much easier/faster.

", "time": "2022-07-25T20:13:45Z"}, {"author": "Jonathan Hoyland", "text": "

I've read the draft

", "time": "2022-07-25T20:13:52Z"}, {"author": "Uri Blumenthal", "text": "

BTW, what's the answer to Jonathan's question?

", "time": "2022-07-25T20:15:13Z"}, {"author": "Christopher Wood", "text": "

Oh, I didn't see it. If it's not answered here in chat, @Jonathan, can I encourage you to send your question to the list for resolution?

", "time": "2022-07-25T20:16:06Z"}, {"author": "Sean Turner", "text": "

@Benjamin Kaduk that is what I heard too

", "time": "2022-07-25T20:16:37Z"}, {"author": "Benjamin Kaduk", "text": "

I would assume that the pilot retains more manual control, relies more on voice with ATC, etc., and that the validation failure just affects the automated systems.

", "time": "2022-07-25T20:16:54Z"}, {"author": "Uri Blumenthal", "text": "

@Benjamin, you mean that, e.g., Autoland stops working?

", "time": "2022-07-25T20:17:19Z"}, {"author": "Benjamin Kaduk", "text": "

That's my assumption. I'd love to hear an authoritative answer rather than my speculation.

", "time": "2022-07-25T20:17:53Z"}, {"author": "Jonathan Hoyland", "text": "

Maybe someone in the room could point the speakers to Zulip?

", "time": "2022-07-25T20:18:32Z"}, {"author": "Andrei Popov", "text": "

Depending on the weather, they may be forced to fly to an alternate airport in the hope to connect to the navigation system there... Or use a good old analog ILS, if available?

", "time": "2022-07-25T20:20:18Z"}, {"author": "Jonathan Hoyland", "text": "

If it's because of OCSP Revoked then there's no chance another airport will succeed

", "time": "2022-07-25T20:20:54Z"}, {"author": "Jonathan Hoyland", "text": "

(Unless it was revoked in the last 7 days and the alternative airport hasn't updated their staple I guess)

", "time": "2022-07-25T20:21:27Z"}, {"author": "Christopher Patton", "text": "

((Breaking news? PSK usage guidelines are now RFCs!)

", "time": "2022-07-25T20:21:36Z"}, {"author": "Benjamin Kaduk", "text": "

Wouldn't the alternative airport have a different cert with different revocation status?

", "time": "2022-07-25T20:21:48Z"}, {"author": "Benjamin Kaduk", "text": "

Yes, breaking news

", "time": "2022-07-25T20:22:02Z"}, {"author": "Jonathan Hoyland", "text": "

Woo! My first RFC!

", "time": "2022-07-25T20:22:29Z"}, {"author": "Christopher Patton", "text": "

Wohoo!

", "time": "2022-07-25T20:23:00Z"}, {"author": "Carrick", "text": "

XD

", "time": "2022-07-25T20:23:58Z"}, {"author": "Andrei Popov", "text": "

Having to go to an alternate airport is kind of a big deal... A lot of upset passengers. And it might be in a different country. And those passengers might have to stay on board, until the issue is resolved, depending on the airport's ability to \"process\" them.

", "time": "2022-07-25T20:24:57Z"}, {"author": "Jonathan Hoyland", "text": "

Isn't the leak broken by the Platform Attestation Token

", "time": "2022-07-25T20:25:40Z"}, {"author": "Jonathan Hoyland", "text": "

the link*

", "time": "2022-07-25T20:25:48Z"}, {"author": "Christopher Wood", "text": "

@DKG, you might consider trading in a platform attestation token for a privacy pass token (in effect using this as a form of attestation for privacy pass)

", "time": "2022-07-25T20:26:08Z"}, {"author": "Jonathan Hoyland", "text": "

@caw Now _that_ is a clever trick

", "time": "2022-07-25T20:27:05Z"}, {"author": "Ashley Kopman", "text": "

Ben is correct that if the DTLS handshaking fails there are alternative channels such as voice. There are aviation specifications for how to handle the failure cases.

", "time": "2022-07-25T20:28:07Z"}, {"author": "Jonathan Hoyland", "text": "

@Nick Doty Because binding stuff to a specific TLS channel is pretty easy (using the Exporter interface)

", "time": "2022-07-25T20:29:24Z"}, {"author": "Jonathan Hoyland", "text": "

This design gives you a place to bind some HTTP action to a TPM, which is really nice.

", "time": "2022-07-25T20:30:24Z"}, {"author": "Thom Wiggers", "text": "

I've moved and wired internet isn't hooked up yet to the home office:(

", "time": "2022-07-25T20:37:19Z"}, {"author": "Bas Westerbaan", "text": "

Dilithium is faster than p256 for verification, but not for signing. Difference isn't dramatic.

", "time": "2022-07-25T20:39:59Z"}, {"author": "Benjamin Kaduk", "text": "

I've heard it a couple times today now ... is \"dilithium\" in the PQC sense pronounced differently than in the Star Trek sense?

", "time": "2022-07-25T20:40:03Z"}, {"author": "Sofia Celi", "text": "

Benjamin Kaduk said:

\n
\n

I've heard it a couple times today now ... is \"dilithium\" in the PQC sense pronounced differently than in the Star Trek sense?

\n
\n

I think the name is from Star Trek but everyone pronounces it in any way

", "time": "2022-07-25T20:41:44Z"}, {"author": "Deb Cooley", "text": "

I've heard it pronounced di-lithium (like the element)

", "time": "2022-07-25T20:41:49Z"}, {"author": "Deb Cooley", "text": "

where the 'di' is 'dI

", "time": "2022-07-25T20:42:21Z"}, {"author": "Deb Cooley", "text": "

(and I've paid no attention where the name came from)

", "time": "2022-07-25T20:42:57Z"}, {"author": "Benjamin Kaduk", "text": "

(Random fun fact: I actually talk about dilithium in my Ph.D. thesis.)

", "time": "2022-07-25T20:44:32Z"}, {"author": "Mike Ounsworth", "text": "

Benjamin Kaduk said:

\n
\n

(Random fun fact: I actually talk about dilithium in my Ph.D. thesis.)

\n
\n

The crypto kind, or the powering-your-starship kind?

", "time": "2022-07-25T20:45:00Z"}, {"author": "Christian Huitema", "text": "

so is it deye-lithium or dee-lithium?

", "time": "2022-07-25T20:45:12Z"}, {"author": "Deb Cooley", "text": "

the first

", "time": "2022-07-25T20:45:24Z"}, {"author": "Benjamin Kaduk", "text": "

The real-world kind: two atoms of lithium bound together in a molecule :)
\nIn my head it's dye-lithium

", "time": "2022-07-25T20:45:32Z"}, {"author": "Bas Westerbaan", "text": "

No. I corrected the pk sizes in your different slides ;)

", "time": "2022-07-25T20:45:35Z"}, {"author": "Carrick", "text": "

@kaduk awesome :)

", "time": "2022-07-25T20:46:00Z"}, {"author": "Martin Thomson", "text": "

@Benjamin Kaduk it's \"die, lithium\", which is a reference to a hatred of batteries

", "time": "2022-07-25T20:46:14Z"}, {"author": "Bas Westerbaan", "text": "

It's nowhere close to 16MB. More like 8KB.

", "time": "2022-07-25T20:46:23Z"}, {"author": "Christian Huitema", "text": "

yuck. Another of those traps for Frech native speakers...

", "time": "2022-07-25T20:46:23Z"}, {"author": "Bas Westerbaan", "text": "

Thom is referring to: https://blog.cloudflare.com/sizing-up-post-quantum-signatures/

", "time": "2022-07-25T20:46:54Z"}, {"author": "Benjamin Kaduk", "text": "

Christian: could you clarify the trap, for us non-native French speakers?

", "time": "2022-07-25T20:47:50Z"}, {"author": "David Benjamin", "text": "

There's a wire limit of 2^24 for messages and 2^16 for some fields (like key share). But implementations often impose tighter limits on messages for DoS reasons. Those aren't standardized anywhere and are ad-hoc.

", "time": "2022-07-25T20:48:10Z"}, {"author": "Christian Huitema", "text": "

\"di\" is the greek prefix for 2. And of course, it is said \"dee\" in French. Or in Greek...

", "time": "2022-07-25T20:48:38Z"}, {"author": "David Benjamin", "text": "

(Because forcing the peer to buffer up 24MiB is a bit much.)

", "time": "2022-07-25T20:48:40Z"}, {"author": "David Benjamin", "text": "

(Sorry, 16MiB)

", "time": "2022-07-25T20:48:48Z"}, {"author": "Benjamin Kaduk", "text": "

thanks!

", "time": "2022-07-25T20:48:53Z"}, {"author": "Bas Westerbaan", "text": "

Yeah, we saw bumps at 10kB and 30kB. https://blog.cloudflare.com/content/images/2021/11/image3-13.png

\n
", "time": "2022-07-25T20:49:04Z"}, {"author": "Bas Westerbaan", "text": "

But with both Dilithium (for handshake) and Falcon (for the rest), we're only looking at 8kB, which is a nice surprise. Still not great, but not terrible. https://blog.cloudflare.com/nist-post-quantum-surprise/

", "time": "2022-07-25T20:49:55Z"}, {"author": "Thom Wiggers", "text": "

(again, Bas' blog post is great)

", "time": "2022-07-25T20:50:39Z"}, {"author": "Christian Huitema", "text": "

QUIC did test carrying 8KB in the handshake. It could work.

", "time": "2022-07-25T20:50:43Z"}, {"author": "Bas Westerbaan", "text": "

8kB is enough.

", "time": "2022-07-25T20:52:26Z"}, {"author": "Thom Wiggers", "text": "

the parameters aren't final yet, so send NIST feedback about the sizes / security levels ;-)

", "time": "2022-07-25T20:53:03Z"}, {"author": "Mike Ounsworth", "text": "

Did I just hear @Martin Thomson ask for something like a liason statement to NIST asking for a less-than-128-bit security level that fits in the TCP window?

", "time": "2022-07-25T20:53:15Z"}, {"author": "Benjamin Kaduk", "text": "

I think you heard that, yes.

", "time": "2022-07-25T20:53:38Z"}, {"author": "Christian Huitema", "text": "

Apart from perf, there are also potential DDOS issues -- sending a train of packets increase the window for mayhem

", "time": "2022-07-25T20:53:46Z"}, {"author": "Thom Wiggers", "text": "

the NIST workshop will be virtual I believe so attending is easy :)

", "time": "2022-07-25T20:53:53Z"}, {"author": "Sean Turner", "text": "

The new text: <t> For a flag that does require a response, the only proper response is the same flag in a flags extension. This extension
\n MUST NOT be used to specify extensions where the response is a proper extension with content.</t>

", "time": "2022-07-25T20:55:01Z"}, {"author": "David Schinazi", "text": "

@MT QUIC servers that do 0-RTT already support receiving multiple packets without RETRY so I think we'll be OK

", "time": "2022-07-25T20:55:03Z"}, {"author": "Martin Thomson", "text": "

@Thom Wiggers that would be good. Let's just say that at the standard 1200 byte limit in QUIC, you can't do Kyber.

", "time": "2022-07-25T20:55:04Z"}, {"author": "Florence D", "text": "

Great presentation, thanks both. And thanks for the blog links.

", "time": "2022-07-25T20:55:20Z"}, {"author": "Sofia Celi", "text": "

here the workshop if interested: https://sofiaceli.com/PQNet-Workshop/ (last years, but it will be updated there). We did took some notes last time: https://sofiaceli.com/PQNet-Workshop/tls.html and https://sofiaceli.com/PQNet-Workshop/dnssec.html

", "time": "2022-07-25T20:55:21Z"}, {"author": "Florence D", "text": "

Somewhat disappointed it wasn't the musical version as promised in CFRG though :wink:

", "time": "2022-07-25T20:55:43Z"}, {"author": "Martin Thomson", "text": "

Thom Wiggers said:

\n
\n

the NIST workshop will be virtual I believe so attending is easy :)

\n
\n

\"easy\" is not quite true if you live in Australia

", "time": "2022-07-25T20:55:47Z"}, {"author": "Sean Turner", "text": "

again the text is: <t> For a flag that does require a response, the only proper response is the same flag in a flags extension. This extension
\n MUST NOT be used to specify extensions where the response is a proper extension with content.</t>

", "time": "2022-07-25T20:55:49Z"}, {"author": "Thom Wiggers", "text": "

Martin Thomson said:

\n
\n

Thom Wiggers that would be good. Let's just say that at the standard 1200 byte limit in QUIC, you can't do Kyber.

\n
\n

A Kyber512 public key is 800 bytes, so that still gives you 400 for the remainder of QUIC, tbf

", "time": "2022-07-25T20:56:24Z"}, {"author": "Thom Wiggers", "text": "

My wiresharking suggested that it would be enough

", "time": "2022-07-25T20:56:39Z"}, {"author": "Thom Wiggers", "text": "

but I'll defer to quicwg if that's true

", "time": "2022-07-25T20:56:53Z"}, {"author": "Jonathan Hoyland", "text": "

+1 for don't care

", "time": "2022-07-25T20:57:06Z"}, {"author": "Martin Thomson", "text": "

@Thom Wiggers I heard that we were looking at something bigger than that. 800 is probably OK.

", "time": "2022-07-25T20:57:24Z"}, {"author": "Sofia Celi", "text": "

Florence D said:

\n
\n

Somewhat disappointed it wasn't the musical version as promised in CFRG though :wink:

\n
\n

next time ;)

", "time": "2022-07-25T20:57:30Z"}, {"author": "Martin Thomson", "text": "

it was Kyber-768 that was too big... Kyber-512 is probably workable

", "time": "2022-07-25T20:58:12Z"}, {"author": "Uri Blumenthal", "text": "

It looks like we'd have to allow it, given the algorithms we got so far.

", "time": "2022-07-25T20:58:30Z"}, {"author": "Mike Ounsworth", "text": "

Martin Thomson said:

\n
\n

it was Kyber-768 that was too big... Kyber-512 is probably workable

\n
\n

Sooo, no liason statement to NIST needed?

", "time": "2022-07-25T20:58:39Z"}, {"author": "Martin Thomson", "text": "

Vote conclusion was that more people wanted to deny an upgrade from the bit to the extension.

", "time": "2022-07-25T21:00:26Z"}, {"author": "Nick Doty", "text": "

meetecho: adjourned.

", "time": "2022-07-25T21:00:59Z"}]