I mean, we'd probably need to burn another codepoint if it does change, but codepoints are cheap. :-)
Did you have any particular changes in mind? On Tue, Oct 8, 2024, 21:17 Eric Rescorla <e...@rtfm.com> wrote: > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
