I'm OK with a code point assignment so that people can test this out. I don't think we're at the point where we know the draft won't change.
-Ekr On Wed, Sep 25, 2024 at 2:36 PM Bas Westerbaan <bas= 40cloudflare....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
