If we want a new name, then I propose kex_hint — keyshare is a DH concept. I'm happy with all proposals so far though — we have been bad at naming, but fortunately consistently so.
On Wed, Sep 25, 2024 at 7:06 PM Andrei Popov <Andrei.Popov= 40microsoft....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
