Archive

On Mon, Oct 5, 2020 at 6:38 PM Martin Thomson <mt@lowentropy.net> wrote:

> 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.
>

You could fix this by requiring the minimal encoding, right?

-Ekr

> 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 <ekr@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
>

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints