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

On Jun 19, 2010, at 9:34 AM, Juho Vähä-Herttua wrote:

> 
> On 19.6.2010, at 2.58, Adam Langley wrote:
>> On Fri, Jun 18, 2010 at 6:12 PM, Juho Vähä-Herttua <juhovh@iki.fi> 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.
Hi Juhu,

need to look into max_fragment_length, but we can use a symbol instead of the constant.
> 
> 
> 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.
uint8 is not enough as stated earlier.
What I do not understand is what you gain by putting the padding_length at the end?
You do not save any space, I think. And it is also not complicated to use the
format the ID currently describes. At least it was implementable in a pretty
straight forward way in OpenSSL.

Best regards
Michael
> 
> 
> Juho
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 