Hi, There's also data from the old Chrome/Cloudflare experiment, in the discussion section: https://blog.cloudflare.com/the-tls-post-quantum-experiment/
I /think/ the discussion says that sending handshake messages somewhat above the MTU didn't matter much, except on the slowest connections. They do hesitate to settle on a reason for that. As for compatibility in general, it seems premature to worry about. If an implementation adds PQC support, and finds it doesn't work for underlying fragmentation reasons, they'll surely have to fix that too. thanks, Rob On Wed, Jul 27, 2022 at 12:06 PM Bas Westerbaan <bas= 40cloudflare....@dmarc.ietf.org> wrote: > On the QUIC side, there is the "*Q*uantum Ready" interop test: > > > https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=438405370 > > > > On Wed, Jul 27, 2022 at 8:57 PM Kampanakis, Panos <kpanos= > 40amazon....@dmarc.ietf.org> wrote: > >> Gotcha. This is a reasonable explanation for a potential problem, but I >> would also like to see experimental proof that DTLS implementation X, Y, Z >> have the problem. TLS implementations don't deal with big ClientHellos >> today so we could assume they would have a problem, but when tested they do >> OK for the most part. >> >> >> -----Original Message----- >> From: TLS <tls-boun...@ietf.org> On Behalf Of Ilari Liusvaara >> Sent: Wednesday, July 27, 2022 10:42 AM >> To: <tls@ietf.org> <tls@ietf.org> >> Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes >> >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you can confirm the sender and know >> the content is safe. >> >> >> >> On Wed, Jul 27, 2022 at 02:27:12AM +0000, Kampanakis, Panos wrote: >> > Hi Ilari, >> > >> > > - DTLS-level fragmentation. There are buggy implementations that >> > > break if one tries this. >> > >> > DTLS servers have been fragmenting and sending cert chains that don’t >> > fit in the MTU for a long time. Is this buggy on the TLS client side? >> >> These problems are specific to fragmenting Client Hello. Handling >> fragmented DTLS Client Hello is different from handling fragmented DTLS >> Certificate (and even more so in DTLS 1.3). I think DTLS specification just >> pretends both cases are the same. They are not. >> >> >> QUIC implementations could have similar issues with multiple initial >> packets, but operating QUIC with fast failure-independent fallback would >> make failures soft. >> >> >> There is the general principle that if some protocol feature is not used >> in the wild, it tends to break, even if required part of the protocol. >> Either by implementation being poorly tested and buggy, assuming the >> feature does not exist, or being missing entierely. >> Combine this with interop failures having outsize impact and old versions >> sticking around far longer than desriable. And I do not think fragmented >> Client Hellos in DTLS or multiple initials in QUIC are seen much. >> >> >> One trick with DTLS would be sending client hello with no key shares. >> Causes extra round-trip, but any server that selects PQC causing >> fragmentation would presumably be capable of handling that. >> >> >> >> -Ilari >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
