Re: [TLS] Minor comments on draft-ietf-tls-dtls-heartbeat

Michael Tüxen <> Thu, 01 September 2011 20:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1737A21F9775 for <>; Thu, 1 Sep 2011 13:02:26 -0700 (PDT)
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 N6Izx3IN0GG5 for <>; Thu, 1 Sep 2011 13:02:25 -0700 (PDT)
Received: from ( [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by (Postfix) with ESMTP id 5497821F9761 for <>; Thu, 1 Sep 2011 13:02:25 -0700 (PDT)
Received: from [] ( []) (Authenticated sender: macmic) by (Postfix) with ESMTP id 11F891C0C0BD9; Thu, 1 Sep 2011 22:03:57 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Michael_T=FCxen?= <>
In-Reply-To: <>
Date: Thu, 1 Sep 2011 22:03:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Eric Rescorla <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [TLS] Minor comments on draft-ietf-tls-dtls-heartbeat
X-Mailman-Version: 2.1.12
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, 01 Sep 2011 20:02:26 -0000

On Sep 1, 2011, at 2:51 AM, Eric Rescorla wrote:

Hi Eric,

thanks a lot for the comments. See my comments in-line.
Accepted changes will be included in rev 03, which I will
submit when the WG LC is closed.

Best regards
> S 1.1.
> "and their adoptions" -> "and their adaptations"
> "as described" -> described
> S 3.
> "Like the ChangeCipherSpec message,.... can arrive at any time"
> I guess a CSS can in principle arrive at any time, but it's not permitted at
> any time. You couldn't send it as the first message of a connection,
> for instance. I'm not sure there is a specific statement to this effect
> in 5246, but it seems implicit in S 7.3.
I think we can just say:
A HeartbeatRequest message can arrive almost at any time during the
lifetime of a connection.
> "MUST stop the retransmission timer" -> "MUST stop the DTLS retransmission
> timer" perhaps?
> "HeartbeatRequest messages from older epochs must be discarded"
> I would clarify that this is DTLS only since TLS has no epochs.
Changed to:
In case of DTLS, HeartbeatRequest messages from older epochs SHOULD be
> S 4.
> You should probably clarify why the padding length is what it is.
OK. It reads now:
The padding is additional arbitrary content which MUST be ignored
by the receiver. The length of a HeartbeatMessage is TLSPlaintext.length
for TLS and DTLSPlaintext.length for DTLS. The length of the type field is 1
byte and the length of the payload_length is 2. Therefore, the
padding_length is TLSPlaintext.length - payload_length - 3 for TLS and
DTLSPlaintext.length - payload_length - 3 for DTLS.
> S 5.1
> We'll need to update the 4347 citation to DTLS 1.2
> 5.2.
> "allows this check" -> "allows a check" perhaps?
> "multiple round trip times"
> You should probably recommend some multiple.
I can't provide a concrete number. The text is based on a suggestion of the transport
area directorate.

The tradeoff is clear: The sooner you send a HB, the sooner you will figure out
that the peer is gone. However, the more traffic you are sending.

From a congestion control point of view, you can send a HB per RTT. But this is covered
by the requirement that you can only have one HB in flight.
> S 6.
> Specification required is a pretty low bar for a field this small... Perhaos
> Expert Review would be better.
> -Ekr
> _______________________________________________
> TLS mailing list