I think it's more important to keep consistent naming between TLS and DNS than to come up with some perfect terminology for this concept. Publishing the full list of groups supported by the server also appears to be more useful: any partial list is but a partial solution to the problem.
Cheers, Andrei -----Original Message----- From: Stephen Farrell <stephen.farr...@cs.tcd.ie> Sent: Wednesday, September 25, 2024 9:30 AM To: David Benjamin <david...@chromium.org> Cc: TLS List <tls@ietf.org> Subject: [EXTERNAL] [TLS] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction Two quick bits... On 9/25/24 16:59, David Benjamin wrote: > If you publish L1+oddballs for all routes to T1 and the client then > predicts oddballs to S1, *this is not a failure*. Yeah, I was imprecise again:-) Yes HRR will kick in, but I think that scenario highlights a failure for this spec to help. That said... >> In that case ISTM the right thing is to publish L1 for T1 and >> L1+oddballs > for T2. > > That would *also* suboptimal for T1. Suppose the client supports > oddballs, saw L1, and predicted something in L1. Then they connect to > S2 but actually > S2 really wants oddballs when the client supports it. Then S2 will HRR. With s/would/could/ that's a fair point, though I don't think we're trying to represent that "really wants...when" via this spec, so one could argue that's out of scope. Anyway, I reckon I've made my point, if others agree they'll chime in, if not, I assume we'll stick with the current presentation syntax, maybe with a bit more clarification, and the DEs will like that or not. Cheers, S. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
