The shorter ID was described as such: "significantly limits future flexibility."
What "flexibility" is lost? thanks, Rob On Tue, Feb 16, 2021 at 4:57 PM Carrick Bartle <cbartle891= [email protected]> wrote: > I see. It seems reasonable to me to leave it as a variable-length vector > to provide flexibility. Since the best mitigation for the privacy issue, > regardless of the length of the config_id, is to have a large anonymity set > as described in Security and Privacy Goals, it doesn't seem like a longer > config_id is, in all cases, a major privacy trade-off. > > > > On Feb 16, 2021, at 4:34 PM, Eric Rescorla <[email protected]> wrote: > > > > On Tue, Feb 16, 2021 at 4:21 PM Carrick Bartle <[email protected]> > wrote: > >> 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"? >> > > It's not long enough to encode much. As a concrete example, what if the > label is actually an encrypted version of the private key? Or you have a > distributed generation algorithm that you don't want to synchronize? > > -Ekr > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
