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

On Mon, Nov 16, 2020 at 7:09 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com>
wrote:

> FWIW the current scheme described in
> https://tools.ietf.org/html/draft-ietf-tls-ctls-01 only offers variable
> length encoded integers of one to three bytes. We need more than that.
>

I think that's easy to fix by  making the longest version 4 bytes. TBH I
had forgotten i used 3.

> I am in favor of the “deterministic” version, if deterministic means no
> overlaps in the encoded number ranges.
>

Yes. So for instance 0x8000 would be 128.

Hence, I am in favor of 2 but would leave the details of how we encode it
> open to work in the group. There are various possible designs and none of
> them is rocket science.
>

Yep. If it looks like we are getting consensus I will work up a proposal.

-Ekr

>
> Ciao
>
> Hannes
>
>
>
> *From:* TLS <tls-bounces@ietf.org> *On Behalf Of * Eric Rescorla
> *Sent:* Sunday, November 15, 2020 9:13 PM
> *To:* Nick Harper <nharper@google.com>
> *Cc:* <tls@ietf.org> <tls@ietf.org>
> *Subject:* Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
>
>
>
> Trying to close out this discussion, it seems to me like there are three
> major options:
>
>
>
> 1. The current scheme
>
> 2. The current scheme with a deterministic minimal encoding (e.g., the two
> byte version is offset by 127)
>
> 3. The QUIC scheme
>
>
>
> I don't think that the QUIC scheme with deterministic encoding makes
> sense, because the virtue of the QUIC scheme is commonality with something
> already defined. I'm hearing that people are not as excited about moving to
> QUIC as I had expected and to the best of my knowledge, there is no valid
> reason to encode to > 2^32-1 in TLS. I also don't think using encoding (1)
> but mandating minimal length makes sense, as it's just as easy to do a
> deterministic minimal encoding.
>
>
>
> As Christian observes it *is* significantly more painful to do (2): the
> conventional way to encode vectors in TLS with minimal copying is:
>
>
>
> - Mark your current place --> X
>
> - Skip forward the length of the length field --> L
>
> - Encode the value
>
> - Encode (current position - (X + L)) at X
>
>
>
> But this won't be possible in (2). As MT observes, if you think of this as
> a two-pass system, there is not as much of a problem here [though not
> necessarily no problem]. Also, if you use a separate buffer, there is no
> problem. As noted above by MT and others, cTLS expands the transcript and
> so having a deterministic compression scheme is perhaps not as important,
> given that decompression is deterministic, but it still seems nice to have.
>
>
>
> Given the above, I think my preference would be (1) or (2), with, I think,
> a slight preference for (2).
>
>
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Oct 6, 2020 at 5:33 PM Nick Harper <nharper@google.com> wrote:
>
> I have no strong opinion on how this is formatted. I'd base my decision on
> what the maximum value cTLS needs to encode: If 2^22-1 is sufficient, let's
> keep it as is, otherwise let's change it to the QUIC format (or some other
> change to increase the max value). I do like that the existing scheme,
> compared to QUIC varints, is more efficient for values 64-127 and just as
> efficient for the rest.
>
>
>
> On Mon, Oct 5, 2020 at 8:09 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
> I don't have a strong opinion on whether to require a minimal encoding,
> but if we're not going to use QUIC's encoding as-is, then I would rather
> stick with the existing scheme, which has twice as large a range for the 1
> byte encoding and is thus more compact for a range of common cases.
>
>
>
> -Ekr
>
>
>
>
>
> On Mon, Oct 5, 2020 at 7:31 PM Marten Seemann <martenseemann@gmail.com>
> wrote:
>
> In that case, why use QUIC's encoding at all? It would just put the burden
> on the receiver to check that the minimal encoding was used.
>
> Would it instead make more sense to modify QUIC's encoding, such that the
> 2-byte encoding doesn't encode the numbers from 0 to 16383, but the numbers
> from 64 to (16383 + 64), and equivalently for 4 and 8-byte encodings?
>
>
>
> On Tue, Oct 6, 2020 at 9:22 AM Salz, Rich <rsalz@akamai.com> wrote:
>
> Can you just say “QUIC rules but use the minimum possible length”?
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>