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

From: [email-masked]
Date: Thu, 27 Jan 2011 03:45:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title           : Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension
	Author(s)       : R. Seggelmann, et al.
	Filename        : draft-ietf-tls-dtls-heartbeat-01.txt
	Pages           : 8
	Date            : 2011-01-27

This document describes the Heartbeat Extension for the Transport
Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
protocol.

The Heartbeat Extension provides a new protocol for TLS/DTLS allowing
the usage of keep-alive functionality without performing a
renegotiation and a basis for path maximum transmission unit (PMTU)
discovery for DTLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls-heartbeat-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Jan 2011 13:38:43 +0100

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

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

---

From: Florian Weimer <[email-masked]>
Date: Thu, 27 Jan 2011 13:00:27 +0000

> Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

I think this paragraph

| There MUST NOT be more than one HeartbeatRequest message in flight
| at a time.

should be changed to:

| Retransmissions MUST use the same payload as the original
| HeartbeatRequest message.

The original requirement seems to be pretty much unimplementable
because of transport layer characteristics.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 27 Jan 2011 14:49:41 +0100

> | HeartbeatRequest message.
The intention of the sentence in the ID is that you can not send
multiple HeartbeatRequest out. This could overload the network since
DTLS uses transport layers which do not necessary provide a congestion
control. That is why you can only have one request in flight.
Please note that it is not in flight anymore if the corresponding
HeartbeatReply has been received or the retransmission timer fires.
> because of transport layer characteristics.
Not sure what problem you are thinking about.
An implementation of the ID for OpenSSL is available at
http://sctp.fh-muenster.de/dtls-patches.html

Best regards
Michael
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 27 Jan 2011 20:02:24 +0100

> 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.
> payload_length, payload and padding fields seems unnecessary to me.
As explained above, I think both fields are necessary.

Best regards
Michael