Re: [TLS] PQC key exchange sizes

[Sofía Celi <[e-mail]>]

Dear, all,

I wrote some of the open challenges of putting post-quantum cryptography 
into protocols over here: https://sofiaceli.com/thoughts/Taxonomy.pdf 
The document is very open ended atm but the idea is to develop into a 
list of concrete problems.

As I mentioned on our talk at the TLS WG meeting, I am planning a next 
instation of this workshop for around November to precesily talk about 
these challenges (the website is not yet updated as some people have 
asked ;)): https://sofiaceli.com/PQNet-Workshop/ I'll send a reminder to 
this list once there is more information about it.

Thank you,

On 27/07/2022 21:54, Rob Sayre wrote:
> Hi,
> 
> There's also data from the old Chrome/Cloudflare experiment, in the 
> discussion section:
> https://blog.cloudflare.com/the-tls-post-quantum-experiment/ 
> <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=[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     On the QUIC side, there is the "*Q*uantum Ready" interop test:
> 
>     https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=438405370
>     <https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=438405370>
> 
> 
> 
>     On Wed, Jul 27, 2022 at 8:57 PM Kampanakis, Panos
>     <kpanos=[e-mail]
>     <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>>
>         On Behalf Of Ilari Liusvaara
>         Sent: Wednesday, July 27, 2022 10:42 AM
>         To: <[e-mail] <mailto:[e-mail]>> <[e-mail]
>         <mailto:[e-mail]>>
>         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
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/tls
>         <https://www.ietf.org/mailman/listinfo/tls>
>         _______________________________________________
>         TLS mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/tls
>         <https://www.ietf.org/mailman/listinfo/tls>
> 
>     _______________________________________________
>     TLS mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tls
>     <https://www.ietf.org/mailman/listinfo/tls>
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls

-- 
Sofía Celi
@claucece
Cryptographic research and implementation at many places, specially Brave.
Chair of hprc at IRTF and anti-fraud at W3C.
Reach me out at: [e-mail]
Website: https://sofiaceli.com/
3D0B D6E9 4D51 FBC2 CEF7  F004 C835 5EB9 42BF A1D6