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 wrote:
> I think it's more important to keep consistent naming between
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
Hi Peter,
back in 2020 I've implemented RFC 8449 for DTLS 1.2 in
Eclipse/Californium. My interest was out of the original scope,
I mainly use it to indirect indicate the preferred UDP message size.
In my opinion, the original scope didn't match the available UDP APIs,
see
https://mailarchive.iet
On Tue, Sep 24, 2024 at 8:04 PM Stephen Farrell
wrote:
> > Avoiding HRR is a matter of predicting the group that the
> > server would have picked given yours and the server's preferences. For
> > example, consider a server that supports:
> >
> > A > B > C > D > E > F
> >
> > By the short list the
On Tue, Sep 24, 2024 at 8:19 PM Watson Ladd wrote:
> On Tue, Sep 24, 2024 at 5:07 PM Stephen Farrell
> wrote:
>
> > >
> > > Could you elaborate on how a long list could result in a failure or add
> > > complexity?
> >
> > Again, I'll try:-)
> >
> > Let's say we have targets T1 and T2. And serve
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,
> We should reap what we sow and just use supported_groups
Agreed 🥲
On Wed, Sep 25, 2024 at 10:54 AM Bob Beck
wrote:
>
>
> On Tue, Sep 24, 2024 at 5:12 PM David Benjamin
> wrote:
>
>> I should add, another reason to call it tls-supported-groups is that this
>> is essentially what the server wo
Hiya,
On 9/25/24 15:50, Bob Beck wrote:
If we absolutely must name the DNS thing something else,
I don't think we absolutely must change, but do think deciding
now is timely, and also that a change is likely better. If we
stick with what's in the I-D now, I'd say a bit of apologetic
text sayi
On Tue, Sep 24, 2024 at 5:12 PM David Benjamin
wrote:
> I should add, another reason to call it tls-supported-groups is that this
> is essentially what the server would have put in the supported_groups
> extension, if negotiation order in TLS were inverted. Since TLS already saw
> fit[*] to name
