* But how are you going to detect whether there's a crappy TCP/IP stack or an attack? You can't. Understood. This is a general problem with insecure client-side fallbacks.
It is unclear what this draft is trying to achieve: * Is this draft paving the way for TLS clients to advertise PQC groups without sending the corresponding key shares? This is available today, and yes servers may or may not HRR in this situation. Server’s decision, depends on a variety of factors. Servers that really care about PQC (or some other distinction between supported groups) will HRR. If this is the problem we’re trying to address, could this just be a security consideration in the PQC drafts? * Is this draft anticipating a new wave of TLS clients performing insecure fallbacks? Server-side protection against this is not effective. Especially when we have both servers that cannot handle large ClientHello messages and servers that have buggy HRR. If this is the concern, would it be better to just say that TLS clients SHOULD NOT/MUST NOT implement insecure fallbacks to weaker TLS parameters? Cheers, Andrei From: Rob Sayre <say...@gmail.com> Sent: Monday, October 16, 2023 4:36 PM To: Andrei Popov <andrei.po...@microsoft.com> Cc: David Benjamin <david...@chromium.org>; tls@ietf.org Subject: Re: [EXTERNAL] Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt On Mon, Oct 16, 2023 at 3:51 PM Andrei Popov <andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote: * Where these interpretations conflict, the selection may be downgraded, potentially even under attacker influence. Downgrade by attacker is only possible if the client attempts insecure fallback (e.g., offer PQ key share, connection failed, retry without PQ key share)? Or am I missing some other possible downgrade attack? I think perhaps. The problem is that PQ key shares are going to be split across packets, and some software is going to break. This is just because our current ClientHellos fit in one packet (or maybe a few, the more you add, the worse it gets). But how are you going to detect whether there's a crappy TCP/IP stack or an attack? You can't. So, as the new things roll out, this will happen. It's not really an interesting problem, but it is real. Think of how TLS 1.3 handshakes pretend to be something older. It's that sort of thing. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
