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

On Jan 27, 2011, at 1:38 PM, Simon Josefsson wrote:

> This looks like a useful extension, it is similar to the unfortunately
> non-standard keepalive feature in SSH (that I happened to implement for
> libssh2 not long ago).
> 
> I have one mild concern with permitting arbitrary payload.  What is the
> rationale for this?  It opens up for a side channel in TLS.  It could
For the payload:
When receiving a HeartbeatResponse the node must check if it matches the
current HeartbeatRequest. By using the simple reflection mode this is
possible. It is possible to do this with a sequence number, but you
might want to measure a round trip time, so you could put in a time stamp
or something else. The point here is that for interoperability, it
does not matter what the payload is, it is only important that it is
reflected.

For the padding:
When doing path MTU discovery you send messages of a particular length.
Since the MTU in one direction can be different from the MTU in the
opposite direction, you can not just reflect the test messages used
to perform path MTU discovery. The packets sent in the backwards
direction need to be small. This can be done by sending a padding which
is dropped by the receiver.
So you could argue that you can use these fields for steganography. We
can add such a statement to the security considerations.
However, both fields are necessary.
> also be abused to send non-standardized data.  Further, is there any
> reason to allow arbitrary sized payload?  In my opinion, the
> payload_length, payload and padding fields seems unnecessary to me.
As explained above, I think both fields are necessary.

Best regards
Michael
> 
> /Simon
> 
>   struct {
>      HeartbeatMessageType type;
>      uint16 payload_length;
>      opaque payload[HeartbeatMessage.payload_length];
>      opaque padding[padding_length];
>   } HeartbeatMessage;
> 
>   The length of a HeartbeatMessage in total MUST NOT exceed 2^14 or
>   max_fragment_length when negotiated as defined in [RFC6066].
> 
>   type  The message type, either heartbeat_request or
>      heartbeat_response.
> 
>   payload_length  The length of the payload.
> 
>   payload  The payload consists of arbitrary content.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 