Re: [TLS] New Cached info draft

[Stefan Santesson <[e-mail]>]

On 10-03-31 9:14 PM, "Marsh Ray" <[e-mail]> wrote:

>> While Marsh explanation sounded quite reasonable to me,
>> the implementors have a technical advantage of being more
>> accustomed to the TLS spec syntax for defining a vector size:
>> 
>> http://tools.ietf.org/html/rfc5246#section-4.3
> 
> It says:
>>    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).
> 
> This requirement does not seem to allow a vector to be made up of
> variable-sized elements as in Stefan's suggestion.

I don't believe this is discussing the same thing.

This is discussing an encoded vector, which is different from the min-max
values of the vector.

As long as it is possible to encode the actual value of the vector within
the min-max values, you can encode the vector with appropriate length.

Example:

      opaque A<1..2^24-1>;

      struct {
          A b<0..2^24-1>;
      } C;

Is legal  <3byte b len><<3byte A len><A>..<3byte A len><A>>

(compare with definition of the Certificate handshake message having this
syntax structure)

while:

      opaque A[16];

      struct {
          A b<23..24>;
      } C;

Would be impossible to encode b correctly since no multiple of A (16 bytes)
can be 23 or 24 bytes.

I don't see the buffer overflow issue. If the receiver receives a vector of
greater length than the max value, it should simply discard the data and
fail the handshake. I'm sure this exception case is defined somewhere.

The only issue I can see is whether the suggested max length is sufficient.
I.e. Is it realistic that a client will send more than 102 digest values of
cached objects.

/Stefan