Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension
RFC 6520

Received changes through RFC Editor sync (changed abstract to 'This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.

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 MTU (PMTU) discovery for DTLS. [STANDARDS-TRACK]')

[Ballot discuss]
The document says:

  The receiving peer SHOULD discard it silently, if it
  arrives during or after the handshake.

I think you need to specify the "or after" part better. Is this a time-based determination, or something based on sequence numbers that show that the packet with the heartbeat arrived later than the packets involved in the handshake?

Note that one side can initiate a handshake at time t0, another side a heartbeat at t1, and the first handshake packet comes to the side that did the heartbeat at t2, t2>t1>t0.

Similarly, it is possible that one side has completed a handshake and and sends a heartbeat right after, but the last packet of the handshake and the hearbeat change order in flight, making the other side think that that heartbeat is being run during a handshake.

You do say that communications should be idle for a period before initiating the heartbeat exchange. I suspect that for PMTU purposes you might want to send some heartbeats immediately in some cases.

[Ballot comment]
Section 4

  When a HeartbeatRequest message is received, a corresponding
  HeartbeatResponse message MUST be sent carrying an exact copy of the
  payload of the HeartbeatRequest.

I know what you mean, but several places in the text contradict this by
giving cases when a response is not to be sent.

---

I wonder why section 5.2 doesn't discuss the question of whether it is
necessary to have both ends transmitting heartbeats, or good enough for
just one to do it.

[Ballot discuss]
The document does not describe how often to send a heartbeat. Calling it
a heartbeat implies that it is sent (and responded) at regular
intervals.

5.1 is pretty obviously not intended to be more than a probe.

5.2 gives some guidance by saying...

  ...allows a check at a much higher rate than the TCP keep-alive

and

  HeartbeatRequest messages SHOULD only be sent after an idle period
  that is at least multiple round trip times long.

I think you need to give *much* better guidance about the lower bound.

You might also suggest a default "idle period", and you should define
what you mean by "idle period".

You really should discuss whether the "idle period" needs to be
configurable.

[Ballot discuss]
This discuss is checking a niggling concern. While I expect the
outcome to be "no change," and for that to happen quickly, I still
wanna ask just in case...

(1) This involves sending partly predictable plaintext messages
that are then encrypted, with predictable, almost identical
cleartext for the responses and so that the keys used on both
sides are derived from the same (pre)master secret.  Has anyone
looked seriously at that specific combination to see if there's
any weakness for any known/conceivable ciphersuite?

(2) I have not done the work asked-for in (1), and know of no
specific problem, but would it make sense, just in case, to have
some bytes early in the heartbeat_response set randomly by the
responder? (Or some such thing to make the plaintexts differ
more.)

(3) If there were to be any weakness then would it be right to say
"If a received HeartbeatResponse message does not contain the
expected payload the message MUST be discarded silently."

[Ballot comment]
Section 3 says, "If no corresponding HeartbeatResponse message has been received after some amount of time, the DTLS/TLS connection MAY be terminated by the user." Who is "the user" in this case? The reason I ask is that I'm afraid this sentence is going to cause some not-so-bright implementers to need instructions like we had to provide in draft-ietf-tcpm-persist, taking it to mean that only an end-user can terminate a DTLS/TLS connection. Do you mean "the application that initiated the HeartbeatRequest can terminate the connection"? Or that "the DTLS/TLS layer can terminate the connection"? A little more clarity here would minimize future stupidity.

Upon approval of this document, IANA will perform the following actions:

ACTION 1:

IANA will assign the following in the TLS ContentType Registry at
http://www.iana.org/assignments/tls-parameters:

Value Description DTLS-OK Reference
TBD heartbeat Y [RFC-to-be]


ACTION 2:

IANA will assign the following in the ExtensionType Values registry at
http://www.iana.org/assignments/tls-extensiontype-values:

Value Extension name Reference
TBD heartbeat [RFC-to-be]


ACTION 3:

IANA will create the following registry at
http://www.iana.org/assignments/tls-parameters:

Registry Name: Heartbeat Message Types
Reference: [RFC-to-be]
Registration Procedures: Expert Review

Value Description DTLS-OK Reference
0 Reserved  [RFC-to-be]
1 heartbeat_request Y [RFC-to-be]
2 heartbeat_response Y [RFC-to-be]
3-254 Unassigned
255 Reserved [RFC-to-be]


ACTION 4:

IANA will create the following registry at
http://www.iana.org/assignments/tls-parameters:

Registry Name: Heartbeat Modes
Reference: [RFC-to-be]
Registration Procedures: Expert Review

Value Description DTLS-OK Reference
0 Reserved  [RFC-to-be]
1 peer_allowed_to_send Y [RFC-to-be]
2 peer_not_allowed_to_send Y [RFC-to-be]
3-254 Unassigned
255 Reserved [RFC-to-be]

Please note that a column specifying whether DTLS is OK for each registration was recently added to every registry at http://www.iana.org/assignments/tls-parameters, per RFC-ietf-tls-rfc4347-bis.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'Transport Layer Security (TLS) and Datagram Transport Layer Security
  (DTLS) Heartbeat Extension'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tls-dtls-heartbeat/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tls-dtls-heartbeat/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

I, Joe Salowey, TLS working group co-chair, am the Document Shepherd for
this document. I have personally reviewed this version of the document
and I believe it to be ready for forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had adequate review from key WG and non-WG members.
The document Shepherd does not have concerns about the depth or breadth
of the reviews. The document has been reviewed by the transport
directorate.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No specific concerns with the document. There has not been an IPR
disclosure for the document.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is broad support within the working group for this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts
Checklist and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document has appropriate references.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations are complete.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Not applicable.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

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.

Working Group Summary

The is broad working group support for this document.

Document Quality

The document has been reviewed by the transport area directorate and
feedback from that review was incorporated into the document. Several
implementations are planned to enhance the support for DTLS to protect
management and other UDP protocols.