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

Michael Tüxen <> Thu, 27 January 2011 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A31A428C14D for <>; Thu, 27 Jan 2011 10:59:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NEO+mjCJZ-DI for <>; Thu, 27 Jan 2011 10:59:22 -0800 (PST)
Received: from ( [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by (Postfix) with ESMTP id 648F73A6828 for <>; Thu, 27 Jan 2011 10:59:22 -0800 (PST)
Received: from [] ( []) (Authenticated sender: macmic) by (Postfix) with ESMTP id 851DE1C0B4626; Thu, 27 Jan 2011 20:02:25 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Michael_T=FCxen?= <>
In-Reply-To: <>
Date: Thu, 27 Jan 2011 20:02:24 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <20110127114502.24680.73782.idtracker@localhost> <>
To: Simon Josefsson <>
X-Mailer: Apple Mail (2.1082)
Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Jan 2011 18:59:23 -0000

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

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
> /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