* 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?
* Clients that assume a server implements the new rules may introduce a downgrade attack on a pre-existing server. From the text, it is not clear to me exactly how. * It updates server behavior to clarify that key shares may not reflect client preferences. * While this algorithm avoids HelloRetryRequest whenever possible, it implicitly assumes the client prefers the values sent in key_share, and that the server has no preferences between any groups. I don’t think so. Servers accepting other than the server’s top-priority group in order to avoid HRR aren’t necessarily doing this because they honor client preferences or assume that key_share reflects client preferences. They may simply find several groups acceptable and consider RTT reduction more important than the strength difference between certain groups. I’m not convinced that this is necessarily wrong, generally. Cheers, Andrei From: TLS <tls-boun...@ietf.org> On Behalf Of Rob Sayre Sent: Monday, October 16, 2023 10:52 AM To: David Benjamin <david...@chromium.org> Cc: tls@ietf.org Subject: [EXTERNAL] Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt On Mon, Oct 16, 2023 at 9:18 AM David Benjamin <david...@chromium.org<mailto:david...@chromium.org>> wrote: I've thus rephrased it in terms of just one group, which I think is much tidier. How does this look to you? https://github.com/davidben/tls-key-share-prediction/commit/310fa7bbddd1fe0c81e3a6865a59880efc901b33 I agree with the sentiment, but I still see one problem. This text seems really tough to write, so I sympathize. The only remaining problem I see is "Restricting to prediction-safe groups". Maybe "Restricting this selection to..."? I don't have a strong opinion, but I'm pretty sure "Restricting to" is not right. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
