Subject: [TLS] Clarification on vectors required

From: "Neil.Young" <[email-masked]>
Date: Thu, 01 Apr 2010 14:41:25 +0200

Hello,

I have a question about how to understand 4.3 of RFC 2246.

The vector definition seems rather clear to me. I have a problem to 
catch the meaning of this statement:
"The length of an encoded vector must be an even multiple of the length 
of a single element (for example, a 17 byte vector of uint16 would be 
illegal). "

Given the following declaration:

opaque             config_data<2^24-1>;

Is this understanding correct:
1) The declaration is slightly incorrect, because the "floor" element is 
missing. I tend to treat it to be 0
2) The number of bytes expressing the length of the vector is 3, large 
enough to count for 2**24-1 bytes
3) If e.g. the size of the vector's data is 2 bytes, do I really have to 
add a pad byte in order to meet the "even multiple" demand?

Sample: Data payload is 0x4711

Is this correct?
00 00 05 47 11 0

Or this?
00 00 05 47 11

Or none?

Kind regards

---

From: "neil.young" <[email-masked]>
Date: Thu, 01 Apr 2010 15:57:47 +0200

Sorry, small correction necessary:

Is this correct?
00 00 02 47 11 0

Or this?
00 00 02 47 11

Regards

Neil.Young schrieb:
> "The length of an encoded vector must be an even multiple of the 
> length of a single element (for example, a 17 byte vector of uint16 
> would be illegal). "
>
> 1) The declaration is slightly incorrect, because the "floor" element 
> is missing. I tend to treat it to be 0
> 3) If e.g. the size of the vector's data is 2 bytes, do I really have 
> to add a pad byte in order to meet the "even multiple" demand?
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Marsh Ray <[email-masked]>
Date: Thu, 01 Apr 2010 09:25:46 -0500

> is missing. I tend to treat it to be 0

Looks like the lower bound is specified everywhere else.

> 2) The number of bytes expressing the length of the vector is 3,
> large enough to count for 2**24-1 bytes

Sounds right to me.

> to add a pad byte in order to meet the "even multiple" demand?

No. The length field does not need to be the same as the size of an
element and it is not included in the "even multiple" requrirement.

> Is this correct? 00 00 02 47 11 0
> 
> Or this? 00 00 02 47 11

Either is correct, you defined it as 'opaque'. The opaque type is for
"single byte entities containing uninterpreted data".

It's only when vectors contain a defined type that this rule applies:
"The length of an encoded vector must be an even multiple of the length
of a single element (for example, a 17 byte vector of uint16 would be
illegal)."

Obviously, if the defined type is itself one byte in size then the even
multiple requirement is always met.

The example in the RFC:
> opaque Datum[3];      /* three uninterpreted bytes */
> Datum Data[9];   /* 3 consecutive 3 byte vectors */

The 9 must be a multiple of 3.

The size of the length field does not need to be the same as the size of
an element of the vector.

There appears to be an unstated exception to the even multiple
requirement for element types that may themselves be of variable length.

This is just my interpretation, however. :-)

- Marsh

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 01 Apr 2010 17:03:19 +0200

> "single byte entities containing uninterpreted data".

Actually not.

00 00 02 47 11 
is correct. It accurately defines the vector contains two bytes of data (47
and 11).

00 00 02 47 11 0
Is incorrect. It advertise that the vector contains 2 bytes of data, but
provides 3 (47 11 00).

/Stefan

---

From: "neil.young" <[email-masked]>
Date: Thu, 01 Apr 2010 18:27:12 +0200

Hi Marsh,

thanks for the response. Meanwhile I got a similar answer from real TLS 
experts :)  Their statement was
"Hmm, no. The above rule states that the encoded size value (that is put 
to the first three bytes in your case) must be a multiple of the vector 
element's size (two in your case). E.g. if a type is defined as uint16 
data<0..2^24-1>, then the sizes encoded as 00 00 01, 00 00 FF and 00 FF 
FF are illegal (as neither of them is a multiple of two). 

If the type is defined as uint16<0..2^24-1>, then the 0x4711 value (one 
uint16 element) will be encoded as 00 00 02 47 11"

This is exactly what you said. The "size" _element_ has to be an even 
multiple of the element size. A  bit confusing, but logical finally.
Regards