On Fri, Oct 13, 2023 at 1:29 AM Rob Sayre <say...@gmail.com> wrote:
> On Wed, Oct 11, 2023 at 8:43 AM David Benjamin <david...@chromium.org> > wrote: > >> Tossed onto GitHub and removed the discussion of authenticated records >> in >> https://github.com/davidben/tls-key-share-prediction/commit/cabd76f7b320ab4f970f396db3d962ca9f510875 >> > > Apologies in advance for this one, but what is the document trying to say > here? > > It says the client "MAY" use the result, Otherwise, it "SHOULD" ignore it? > It is probably better to get more direct: > > "If the resulting prediction is consistent with client preferences, as > described in {{tls-client-behavior}}, the client MAY use the result to > predict key shares in the initial ClientHello." > > That's probably the way to go, since I think the goal is to avoid obsolete > negotiations. I think this one works, because the server can always insist > on an algorithm, and the client can ignore the DNS recommendation. But, a > flaw of RFC 2119 is that a "SHOULD" ropes in "there may exist valid reasons > in particular circumstances". So.... the circumstances would be troubling! > Use bad encryption due to reasons? It's probably better not to put that > sentence in. > Thanks! I agree that is weird. I went to rewrite it and, as I did, I realized that text is actually kinda weird in lots of ways. It's written as if the client might predict multiple named groups, but once we've gotten a decent signal of what the server supports, I can't imagine why anyone would bother with multiple. I've thus rephrased it in terms of just one group, which I think is much tidier. How does this look to you? https://github.com/davidben/tls-key-share-prediction/commit/310fa7bbddd1fe0c81e3a6865a59880efc901b33 David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
