Draft: draft-ietf-mls-protocol

Commentary: There are two changes in this PR : Pull the extension to the TLS syntax up into the Terminology section Add an extension that lets vectors have variable - length headers , allowing them to be efficient at small sizes while also accommodating large sizes All vectors are converted to the variable - length header representation . It seems like this should simplify implementation , since the encoder will no longer have to be told how many bytes of header to use for a given vector . This has been the source of several annoying interop bugs . 
 Looks great ! I only have a small objection : there is now several valid ways to serialize a length , as the example shows , both and are valid ways to encode 37 . This means that if you parse a structure , and later want to re - serialize it to check a signature for example , you need to remember how many bits were used to store the length . In short , we loose the property that . The fix is easy : can we add that " the length MUST be stored using the smallest amount of bits possible " ? 
 Good point , updated ! 
 I was n't clear under which circumstances you would use a longer length with a number that would fit in a smaller range . If never , then the table should be : 
 DIscussion on virtual interim Some concern about being able to send gigantic stuff In adversarial cases , the 4 - byte headers used for a lot of stuff might already be a problem Could also have length constraints decoupled from the syntax SIP experience shows that imposing arbitrary length limits is n't a good idea ... but applications should have a way to signal that things are too big  ( Advisory text " Beware , things can get big ; consider imposing limits and clear failure cases for this " Consider streaming implementations , where you might not know that the whole message fits in memory Modulo the above TODO , clear to merge
Paragraph (version A):
We use the TLS presentation language RFC8446 to describe the
structure of protocol messages.
Paragraph (version B):
We use the TLS presentation language RFC8446 to describe the
structure of protocol messages.  In addition to the base syntax, we
add two additional features, the ability for fields to be optional
and the ability for vectors to have variable-size length headers.
Paragraph (version B):
An optional value is encoded with a presence-signaling octet,
followed by the value itself if present.  When decoding, a presence
octet with a value other than 0 or 1 MUST be rejected as malformed.
Paragraph (version B):
In the TLS presentation language, vectors are encoded as a sequence
of encoded elements prefixed with a length.  The length field has a
fixed size set by specifying the minimum and maximum lengths of the
encoded sequence of elements.
Paragraph (version B):
Such a vector can represent values with length from 0 bytes to 2^62
bytes.  The variable-length integer encoding reserves the two most
significant bits of the first byte to encode the base 2 logarithm of
the integer encoding length in bytes.  The integer value is encoded
on the remaining bits, in network byte order.  The encoded value MUST
use the smallest number of bits required to represent the value.
When decoding, values using more bits than necessary MUST be treated
as malformed.
Paragraph (version B):
This means that integers are encoded on 1, 2, 4, or 8 bytes and can
encode 6-, 14-, 30-, or 62-bit values respectively.
Paragraph (version B):
For example, the eight-byte sequence c2 19 7c 5e ff 14 e8 8c (in
hexadecimal) decodes to the decimal value 151288809941952652; the
four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte
sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37
(as does the two byte sequence 40 25).
Paragraph (version B):
The use of variable-size integers for vector lengths allows vectors
to grow very large, up to 2^62 bytes.  Implementations should take
care not to allow vectors to overflow available storage.  To
facilitate debugging of potential interoperatbility problems,
implementations should provide a clear error when such an overflow
condition occurs.
Paragraph (version A):
As some nodes may be blank while others contain data we use the
following struct to include data if present.