Oh, I consider that to be a feature. One that I exploit. It's sometimes awkward to build a structure then prepend a length that has a variable-length encoding. If you know the maximum length, the varint encoding allows you to avoid having to move memory.
That said, cTLS won't authenticate both the value and the specific encoding of numeric values as the varint encoding is erased. I don't consider that to be a serious problem, but it means that cTLS transcripts can't be directly compared. I would note that in the draft: people shouldn't be processing cTLS messages that way, but they might be surprised to learn of this. On Tue, Oct 6, 2020, at 12:31, Marten Seemann wrote: > One thing that’s a bit annoying about QUIC’s variant format is that > there are multiple ways to encode a number. This has led to some > complications in the specification (e.g. QUIC requires you to use the > minimal encoding for frame types, but allows all encodings everywhere > else). > It would be nice to have an unambiguous way to encode a number. > > On Tue, Oct 6, 2020 at 07:35 Eric Rescorla <e...@rtfm.com> wrote: > > Hi folks, > > > > cTLS uses a bespoke varint format. Now that QUIC is nearly done, I propose > > adopting their varint format. > > > > https://github.com/tlswg/draft-ietf-tls-ctls/pull/28 > > > > Any objections? > > -Ekr > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
