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
