On Mon, Nov 16, 2020 at 7:09 AM Hannes Tschofenig <hannes.tschofe...@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-boun...@ietf.org> *On Behalf Of * Eric Rescorla > *Sent:* Sunday, November 15, 2020 9:13 PM > *To:* Nick Harper <nhar...@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 <nhar...@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 <e...@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 <martenseem...@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 <rs...@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. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
