> It's not significant extra complexity to have this field bigger and it > basically makes it impossible to have any structure.
What do you mean by structure? How does a byte not provide sufficient "structure"? > On Feb 16, 2021, at 3:33 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Tue, Feb 16, 2021 at 3:01 PM Martin Thomson <m...@lowentropy.net > <mailto:m...@lowentropy.net>> wrote: > On Wed, Feb 17, 2021, at 08:31, Christopher Wood wrote: > > That's true, but I'd personally prefer one tracking vector to two. This > > structure also better aligns with other proposed use cases for HPKE > > configurations. I also don't see an immediate need for flexibility in > > this value given that there are extensions in ECHConfigContents already. > > I don't see the tracking angle as relevant here. The only things that might > matter is size, collision probability (for greasing), and consistency. Size > doesn't matter, because it's a handful of bytes at most; collisions matter > little because the cost is a resource the server is prepared to spend anyway; > consistency with something that can also change isn't worth much. > > The primary argument I would have in support of this is YAGNI. The number of > active keys should be much smaller than 256, and there's a slot for > extensions should that need arise. > > I don't find YAGNI that persuasive in this case. It's not significant extra > complexity to have this field bigger and it basically makes it impossible to > have any structure. > > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
