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
Both of these are very good concerns about the compatibility risk.
I think David's alternative of having a new extension (eg, server_name_ip)
might address a bunch of the issues and be cleaner than any of the other
hacks.
It would have a higher implementation overhead, but also might be more
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.
I agree this is quite a compatibility risk. In addition to messing with SNI
lookup, there are servers that try to correlate TLS SNI and HTTP Host.
Indeed, when we accidentally sent IP literals in SNI, we broke a server
that tried to do that but got very confused by the colons in an IPv6
literal.
Hi Erik,
As far as it goes, this might work. However, I'm not sure about the effect of
this on compatibility. I'm concerned that maybe this would end up causing some
servers to choke. Servers that receive SNI can sometimes use that SNI value to
lookup the correct certificate. Your design
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 wrote:
> Gotcha. This is a reasonable explanation for a potential problem,
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
Following discussions in ADD around the DDR draft (as well as in UTA
around Martin Thomson's PR to add IP address SANs to 6125-bis),
I wrote up a draft on how IP addresses might be represented in SNI:
https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
There are at least three
On Wed, Jul 27, 2022 at 02:27:12AM +, 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
On Tue, Jul 26, 2022, at 22:21, Kampanakis, Panos wrote:
> Why are 2-3 packet CHs unworkable?
Loss probability is a contributing factor for sure, but the thing that really
hurts is the extra round trip that many servers will induce when they cannot
process the TLS ClientHello in one go.
10 matches
Mail list logo
