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=40cloudflare....@dmarc.ietf.org
<mailto: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
<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
<mailto: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 <mailto:tls-boun...@ietf.org>>
On Behalf Of Ilari Liusvaara
Sent: Wednesday, July 27, 2022 10:42 AM
To: <tls@ietf.org <mailto:tls@ietf.org>> <tls@ietf.org
<mailto: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 <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@ietf.org
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: cheren...@riseup.net
Website: https://sofiaceli.com/
3D0B D6E9 4D51 FBC2 CEF7 F004 C835 5EB9 42BF A1D6
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
