Skip to main content

Datagram Transport Layer Security
RFC 4347

Revision differences

Document history

Date Rev. By Action
2021-02-02
05 (System)
Received changes through RFC Editor sync (changed abstract to 'This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol …
Received changes through RFC Editor sync (changed abstract to 'This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.', changed standardization level to Historic)
2021-01-25
05 Amy Vezza New status of Historic approved by the IESG
https://datatracker.ietf.org/doc/status-change-tls-oldversions-to-historic/
2015-10-14
05 (System) Notify list changed from ekr@networkresonance.com to (None)
2012-08-22
05 (System) post-migration administrative database adjustment to the Yes position for Ted Hardie
2012-08-22
05 (System) post-migration administrative database adjustment to the Yes position for Allison Mankin
2009-05-27
(System)
2009-05-18
(System)
2008-10-30
(System)
Posted related IPR disclosure: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, …
Posted related IPR disclosure: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
2006-04-28
05 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2006-04-28
05 Amy Vezza [Note]: 'RFC 4347' added by Amy Vezza
2006-04-26
05 (System) RFC published
2005-06-29
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-06-24
05 Amy Vezza IESG state changed to Approved-announcement sent
2005-06-24
05 Amy Vezza IESG has approved the document
2005-06-24
05 Amy Vezza Closed "Approve" ballot
2005-06-24
05 Russ Housley State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Russ Housley
2005-06-24
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-06-24
05 (System) New version available: draft-rescorla-dtls-05.txt
2005-06-20
05 Russ Housley
Allison, Mark Allman, Eric Rescorla and I have reached consensus on text that will resolve the network congestion issue.  A revised I-D that includes the …
Allison, Mark Allman, Eric Rescorla and I have reached consensus on text that will resolve the network congestion issue.  A revised I-D that includes the revised text will be published soon.  As soon as it is, the document can be approved.
2005-06-20
05 Allison Mankin
[Ballot comment]
Worked with Mark Allman and Ekr to edit the RTO/rtx discussion so it's congestion-aware, based on
RFC 2988.  DCCP  needs to be …
[Ballot comment]
Worked with Mark Allman and Ekr to edit the RTO/rtx discussion so it's congestion-aware, based on
RFC 2988.  DCCP  needs to be careful when it writes DTLS/DCCP, as does DTLS/unordered SCTP.
2005-06-20
05 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to Yes from Discuss by Allison Mankin
2005-05-12
05 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation - Defer by Amy Vezza
2005-05-12
05 Allison Mankin
[Ballot discuss]
Overall excellent specification...and each iteration has improved it.

Here are the results from the review by Mark Allman.  He didn't write it up …
[Ballot discuss]
Overall excellent specification...and each iteration has improved it.

Here are the results from the review by Mark Allman.  He didn't write it up
formally, but he send a note advising us to request changes in 4.2.4.1 as follows:

  why is 793 the
  reference instead of 2988.  The document seems to use a static timeout
  of 500msec when 2988 calls for a min of 1sec.  That discrepency seems to
  warrant justification.  (SCTP also uses such a timeout, I believe --
  i.e., it's general advice.)  Also, 2988 allows for a maximum RTO of 60
  seconds rather than the 240 seconds called for by DTLS.

I think you authors should provide an answer to the discrepancy by pointing
out that this is for an RTO used only in a handshake phase, whereas TCP's
RTO is for all of its traffic and also TCP's has a consequence for its throughput, so
underestimation is a bad choice.  But still, the 2988 reference is the right one,
rather than 793. 

  Implementations SHOULD start the
  timer value at the initial value with each new flight of
  messages.

The timer should stay at the backed-off value until a transmission without
loss occurs, at which point it can be collapsed back down to the initial
value.  (Mark supported this view).  During a period of congestion, your
SHOULD is likely to make large populations worsen congestion by
retransmitting early into that congestion.  2988 btw might advise some
implementors to measure for the subsequent transmissions.

For the purposes of the overall implementation, RTO can also
collapsed back down to the initial value after some time period without
any flights (for instance some multiple of RTO).
2005-05-12
05 Allison Mankin [Ballot Position Update] New position, Discuss, has been recorded for Allison Mankin by Allison Mankin
2005-05-12
05 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2005-05-11
05 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2005-05-11
05 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-04-26
05 (System) Removed from agenda for telechat - 2005-04-25
2005-04-25
05 Amy Vezza State Changes to IESG Evaluation - Defer from IESG Evaluation by Amy Vezza
2005-04-25
05 Michelle Cotton
IANA Comments:
Upon approval the IANA will assign a value for a new handshake message,
hello_verify_request (suggested value 3).  This assignment will be made in …
IANA Comments:
Upon approval the IANA will assign a value for a new handshake message,
hello_verify_request (suggested value 3).  This assignment will be made in a registry created by draft-ietf-tls-rfc2246-bis.  This document itself does not create any new registries.
2005-04-25
05 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen
2005-04-25
05 Bert Wijnen
[Ballot comment]
Comments recorded here to ensure they get picked up.
Author (Eric) has already agreed to make sure these nits
will be addressed.

From …
[Ballot comment]
Comments recorded here to ensure they get picked up.
Author (Eric) has already agreed to make sure these nits
will be addressed.

From AAA-doctors review (Jari):

Its a great spec! Some minor nits below, however. Hope
you find them useful...

> 4.1.1. Transport Layer Mapping
>
>    Each DTLS record MUST fit within a single datagram. In order
>    to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD
>    determine the MTU and send records smaller than the MTU. DTLS
>    implementations SHOULD provide a way for applications to
>    determine the value of the PMTU (or alternately the maximum
>    application datagram size, which is the PMTU minus the DTLS
>    per-record overhead). If the application attempts to send a

>    ...
>
> 4.1.1.1. PMTU Discovery
>
>    In general, DTLS's philosophy is to avoid dealing with PMTU
>    issues. The general strategy is to start with a conservative
>    MTU and then update it if events require it, but not actively
>    probe for MTU values. PMTU discovery is left to the
>    application.

I think I know what you intend to do here, but the above two
text pieces appear to be in conflict. And isn't PMTU probing is
more or less what you are doing in Section 4.1.1.1 anyway?

Suggest changing the latter text to "The general strategy
is to start with a conservative MTU and then update it if
events either during the handshake or actual application
data transport phase require it."

>    The PMTU SHOULD be initialized from the interface MTU that
>    will be used to send packets. If the DTLS implementation
>    receives an RFC 1191 [RFC1191] ICMP Destination Unreachable
>    message with the "fragmentation needed and DF set" Code
>    (otherwise known as Datagram Too Big) it should decrease its
>    PMTU estimate to that given in the ICMP message. A DTLS
>    implementation SHOULD allow the application to occasionally
>    reset its PMTU estimate. The DTLS implementation SHOULD also
>    allow applications to control the status of the DF bit. These
>    controls allow the application to perform PMTU discovery.

How does this play with RFC 1981, IPv6 version of PMTU discovery?
At least the ICMPs are different, and the IPv6 version appears to
say something more specific about the aging of PTMU information.

Suggest adding "RFC 1981 procedures SHOULD be followed for
IPv6.", or something to this effect.

>      2. An attacker can use the server as an amplifier by
>      sending connection initiation messages with a forged source
>      of the victim. The server then sends its next message (in
>      DTLS, a Certificate message, which can be quite large) to
>      the victim machine, thus flooding it.
> ...
>    Although DTLS servers are not required to do a cookie
>    exchange, they SHOULD do so whenever a new handshake is
>    performed in order to avoid being used as amplifiers. If the
>    server is being operated in an environment where amplification
>    is not a problem, the server MAY choose not to perform a
>    cookie exchange. In addition, the server MAY choose not do to
>    a cookie exchange when a session is resumed. Clients MUST be
>    prepared to do a cookie exchange with every handshake.

This is pretty good stuff.

But given that the victim is a different entity than the one that
decides whether the cookies are used, I wonder if you should say
this slightly differently. Maybe "DTLS servers SHOULD perform
a cookie exchange whenever a new handshake is being performed.
If the server is being operated in an environment where amplification
is not a problem, the server MAY be configured to not to perform a
cookie exchange. The default SHOULD be that the exchange is performed,
however.  In addition, the server MAY choose not do to a cookie
exchange when a session is resumed. Clients MUST be
prepared to do a cookie exchange with every handshake."

>    layer security protocol. SIP, for instance, uses a subsert of

s/subsert/subset/

>    Multiple DTLS records may be placed in a single datagram. hey

s/hey/They/

>    Section 3.4.3 of [RFC 2402]

s/]/]./

> A.1?Summary of new syntax

Non-ascii char.
2005-04-25
05 Bert Wijnen [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen
2005-04-25
05 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-04-24
05 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2005-04-24
05 Sam Hartman
[Ballot comment]
I suspect that some more examples will be needed as we find out how
people manage to read this spec and make non-interoperable …
[Ballot comment]
I suspect that some more examples will be needed as we find out how
people manage to read this spec and make non-interoperable
implementations.  This seems like a fine level of detail for a
proposed standard but probably will need revisions for draft.  Overall quite well done.
2005-04-24
05 Sam Hartman [Ballot Position Update] New position, Yes, has been recorded for Sam Hartman by Sam Hartman
2005-04-23
05 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-04-22
05 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to Yes from Discuss by Ted Hardie
2005-04-21
05 Ted Hardie
[Ballot discuss]
In line with the proposal to always reference where the format
syntax is derived, this document probably needs to have an
explicit reference …
[Ballot discuss]
In line with the proposal to always reference where the format
syntax is derived, this document probably needs to have an
explicit reference to the document in which it is defined. 
RFC2246 has this text:

  This document deals with the formatting of data in an external
  representation. The following very basic and somewhat casually
  defined presentation syntax will be used. The syntax draws from
  several sources in its structure. Although it resembles the
  programming language "C" in its syntax and XDR [XDR] in both its
  syntax and intent, it would be risky to draw too many parallels. The
  purpose of this presentation language is to document TLS only, not to
  have general application beyond that particular goal.

so I presume 2246 is its own reference.  2246-bis-10 retains
the same language.  I believe either could be used as
the reference for DTLS.  Given the other references to 2246-bis-10,
I'd suggest making it the reference for this explicitly and
calling it done.  Possibly just changing the sentence in
Section 4:

  Therefore, instead of presenting DTLS as a new
  protocol, we instead present it as a series of deltas from TLS
  1.1 [TLS11].

Therefore, instead of presenting DTLS as a new
  protocol, we instead present it as a series of deltas from TLS
  1.1 [TLS11], using the same syntax as in [TLS11].
2005-04-21
05 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to Discuss from Undefined by Ted Hardie
2005-04-21
05 Ted Hardie
[Ballot comment]
Nits:

However, over the past few years an increasing number of
  application layer protocols have been designed which UDP
  transport.

--> …
[Ballot comment]
Nits:

However, over the past few years an increasing number of
  application layer protocols have been designed which UDP
  transport.

--> which use UDP as a transport.

SIP, for instance, uses a subsert of
  S/MIME to secure its traffic.

-->subset of S/MIME

it typically require a large amount of effort to design

--->requires

using the following sliding, window procedure

--->sliding window procedure?
2005-04-21
05 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie
2005-04-21
05 Brian Carpenter
[Ballot comment]
Review comments from Joel Halpern:

One minor suggestion occurred to me reading this.  It would be helpful to have a paragraph or so …
[Ballot comment]
Review comments from Joel Halpern:

One minor suggestion occurred to me reading this.  It would be helpful to have a paragraph or so indicating what should be done if using a transport like DCCP which does order preservation but not loss prevention.  My guess is that we should just use this protocol, because the cost of extra serial numbers and a few checks is tiny.  But it would be nice if the document said so.

typo:
last paragraph of 4.1.:
    in a single datagram.  hey
                                  ^
                                  T
2005-04-21
05 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-04-13
05 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-04-12
05 Russ Housley [Ballot Position Update] New position, Yes, has been recorded for Russ Housley
2005-04-12
05 Russ Housley Ballot has been issued by Russ Housley
2005-04-12
05 Russ Housley Created "Approve" ballot
2005-04-12
05 Russ Housley State Changes to IESG Evaluation from Waiting for Writeup::AD Followup by Russ Housley
2005-04-12
05 Russ Housley Placed on agenda for telechat - 2005-04-25 by Russ Housley
2005-04-11
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-04-11
04 (System) New version available: draft-rescorla-dtls-04.txt
2005-03-28
05 Russ Housley State Changes to Waiting for Writeup::Revised ID Needed from Waiting for Writeup by Russ Housley
2005-03-28
05 Russ Housley State Change Notice email list have been change to ekr@networkresonance.com from ekr@rtfm.com
2005-03-25
05 (System) State has been changed to Waiting for Writeup from In Last Call by system
2005-02-25
05 Amy Vezza Last call sent
2005-02-25
05 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-02-25
05 Russ Housley State Changes to Last Call Requested from AD Evaluation::AD Followup by Russ Housley
2005-02-25
05 Russ Housley Last Call was requested by Russ Housley
2005-02-25
05 (System) Ballot writeup text was added
2005-02-25
05 (System) Last call text was added
2005-02-25
05 (System) Ballot approval text was added
2005-02-21
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-02-21
03 (System) New version available: draft-rescorla-dtls-03.txt
2005-02-08
05 Russ Housley State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Russ Housley
2005-02-08
05 Russ Housley Comments sent to the authors.  A revised I-D is needed to resolve them.
2005-01-04
05 Russ Housley State Changes to AD Evaluation from Publication Requested by Russ Housley
2004-12-07
02 (System) New version available: draft-rescorla-dtls-02.txt
2004-12-03
05 Russ Housley State Changes to Publication Requested from AD is watching by Russ Housley
2004-11-12
05 Russ Housley Shepherding AD has been changed to Russ Housley from Steve Bellovin
2004-07-19
01 (System) New version available: draft-rescorla-dtls-01.txt
2004-01-29
05 Steven Bellovin State Change Notice email list have been change to ekr@rtfm.com from
2004-01-29
05 Steven Bellovin Draft Added by Steve Bellovin
2004-01-13
00 (System) New version available: draft-rescorla-dtls-00.txt