Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-00.txt

[Juho Vähä-Herttua <[e-mail]>]

On 19.6.2010, at 2.58, Adam Langley wrote:
> On Fri, Jun 18, 2010 at 6:12 PM, Juho Vähä-Herttua <[e-mail]> wrote:
>> The notation "opaque payload<0..2^14-5>" is strange, usually this notation is used like "opaque payload<0..2^16-1>" which means "two length bytes followed by N data bytes". There is no common data type that would have a maximum value of "2^14-5", but there is a common data type with maximum value of "2^16-1", that is the unsigned 16-bit integer. Since the maximum total length of 2^14-5 is already explained in the following sentence, it should be no problem to change it as "2^16-1".
> 
> RFC 5246 section 4.3 is quite clear about the meaning of 2^14-5. It's
> better to be precise in the structure.

It does, however both 2^14-5 and 2^16-1 are not real ceilings because they depend on each other. In RFC 5246 variable-length vectors are only used in handshake protocol, which can be fragmented into several records, and therefore additional restrictions regarding the vector length are not necessary. Also if max_fragment_length of RFC-4366-bis is going to be also supported by the implementation, using length of 2^14-5 will also break the heartbeat protocol.

I would prefer something like:

   struct {
      HeartbeatMessageType type;
      opaque payload[HeartbeatParameters.payload_length];
      opaque padding[HeartbeatMessage.padding_length];
      uint16 padding_length;
   } HeartbeatMessage;

The padding_length could be uint8 as well, unless there's some reason for it to be uint16. Also it should be mentioned that the total length of HeartbeatMessage shouldn't exceed the length of maximum TLSPlaintext fragment size, instead of just using 2^14-5.


Juho