Datagram Transport Layer Security Version 1.2
draft-ietf-tls-rfc4347-bis-06

[Ballot discuss]
The Gen-ART Review by Miguel Garcia on 12-Dec-2010 raised a question
  about Section 4.1 that deserves a response.  The reivew says:

  Section 4.1, previous last paragraph on page 8: The sentence requires
  implementations to compute the TCP maximum segment lifetime. If an
  implementation runs DTLS over UDP, how can it compute the TCP maximum
  segment lifetime, which is a parameter for a different protocol? I
  suspect DTLS implementations running over UDP (or even SCTP) will not
  have a clue of what is the TCP maximum segment lifetime.

[Ballot comment]
This is a fine document and I generally support its publication. However I have 1 minor issues which I would like to discuss before recommending approval of this document:

1). 7. IANA Considerations

  This document uses the same identifier space as TLS [TLS12], so no
  new IANA registries are required.  When new identifiers are assigned
  for TLS, authors MUST specify whether they are suitable for DTLS.

Does this mean that this document Updates [TLS12]?
Section 4.1.2.5 also confirms that.

To be specific: I am missing "Updates: RFC 5246" in the header of this document.


SCTP, RC4, SCTP-AUTH should have Informative references.

[Ballot discuss]
This is a fine document and I generally support its publication. However I have 1 minor issues which I would like to discuss before recommending approval of this document:

1). 7. IANA Considerations

  This document uses the same identifier space as TLS [TLS12], so no
  new IANA registries are required.  When new identifiers are assigned
  for TLS, authors MUST specify whether they are suitable for DTLS.

Does this mean that this document Updates [TLS12]?
Section 4.1.2.5 also confirms that.

To be specific: I am missing "Updates: RFC 5246" in the header of this document.

[Ballot discuss]
(Sorry this was garbled before)

A small but important point, I think.

Section 4.3 needs to include a reference to RFC 5246 for the defnition of the syntax used. This is important (not withstthat the changes are relative to 5246) because although the format looks like 'C' it is not 'C'

[Ballot comment]
I support Alexey's Discuss about description of the changes since/to 4347

---

Should the version numbering be recorded by IANA?

---

How is wrapping of epoch and sequence number handled? Or is it considered that they will never need to wrap?

---

It might be valuable to repeat the UDP warning from 4.1.2.7 in section 5

---

Section 4.3

  This section includes specifications for the data structures that
  have changed between TLS 1.2 and DTLS.

I think s/DTLS/DTLS 1.2/

---

[Ballot discuss]
A small but important point, I think.

Section 4.3 needs to inanding the factwithstclude a reference to RFC 5246 for the defnition of the syntax used. This is important (not that the changes are relative to 5246) because although the format looks like 'C' it is not 'C'

[Ballot comment]
placeholder for Charlie Kaufman's secdir review - this deserves a response.  I made this a comment since I know that the sponsoring AD intends to seem them addressed.

[Ballot discuss]
The Gen-ART Review by Miguel Garcia on 12-Dec-2010 raised a question
  about Section 4.1 that deserves a response.  The reivew says:

  Section 4.1, previous last paragraph on page 8: The sentence requires
  implementations to compute the TCP maximum segment lifetime. If an
  implementation runs DTLS over UDP, how can it compute the TCP maximum
  segment lifetime, which is a parameter for a different protocol? I
  suspect DTLS implementations running over UDP (or even SCTP) will not
  have a clue of what is the TCP maximum segment lifetime.

[Ballot comment]
Just as RFC 5246 describes the major differences between TLS 1.1 and TLS 1.2, I think this document needs a section that describes the major differences between DTLS 1.1 and DTLS 1.2.

[Ballot comment]
1. The document does not have a "Changes from DTLS 1.0 (RFC4347)" section which is customary in 'bis' documents. Why?

2. For the completeness, when referring to PMTU discovery, in addition to
RFC1191 one should probably also refer to RFC1981 (the IPv6 version).

    [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
                Work in Progress, October 2003.

... this should probably be rfc5406?

    [IKEv2]    C. Kaufman (ed), "Internet Key Exchange (IKEv2) Protocol",
                RFC 4306, December 2005.

    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
                December 2005.

... remove the latter 'reference' (edit glitch?)

[Ballot discuss]
The DISCUSS and COMMENT is largely based on the OPS-DIR review by Pekka Savola. I did not see the issues raised by Pekka answered and I believe that part of them (listed below) need to be addressed.

1. The document does not describe how DTLS 1.2 will interwork with DTLS 1.0 (if it will). The TLS 1.2 spec (RFC5246, Appendix E.1) does have some that will apply, but there are likely some DTLS specifics as well.

2.

> 3.2.3. Message Size

    TLS and DTLS handshake messages can be quite large (in theory up to
    2^24-1 bytes, in practice many kilobytes).  By contrast, UDP
    datagrams are often limited to <1500 bytes if fragmentation is not
    desired.  In order to compensate for this limitation, each DTLS
    handshake message may be fragmented over several DTLS records.  Each
    DTLS handshake message contains both a fragment offset and a fragment
    length.

> 4.1.1. Transport Layer Mapping

    Each DTLS record MUST fit within a single datagram.  In order to
    avoid fragmentation, clients of the DTLS record layer SHOULD attempt
    to size records so that they fit within any PMTU estimates obtained
    from the record layer.

... these seem somewhat contradictory.  Maybe I'm missing something.  The latter seems to be saying that DTLS implementations should try to avoid IP fragmentation, but the former seems to imply that it's de-facto mode of operation.

3.
>      If there is a transport protocol indication (either via ICMP or via a
    refusal to send the datagram as in DCCP Section 14), then DTLS record
    layer should inform the upper layer protocol of the error.

Why a 'should'?  I've have thought that it would be natural that if DTSLS record layer gets this notification (which, in the case of ICMP and omitting information, is not necessarily given), it MUST pass this information up. Note that the refusal to send could also apply to UDP if packet is bigger than PMTU and DF bit is set or IPv6 is used.
What is the alternative if it doesn't?  It would be fine if the alternative is that the DTLS record layer react to that information itself, but completely ignoring e.g. ICMP packet too big would lead to communication failure

4.

> 7. IANA Considerations


    This document uses the same identifier space as TLS [TLS12], so no
    new IANA registries are required.  When new identifiers are assigned
    for TLS, authors MUST specify whether they are suitable for DTLS.

... this may be inadequate.  I was unable to find from the registry
(tls-parameters) which of these parameters this applies to.  All of them?

If I understand what you mean, 1) you should actually be asking IANA to reformat the registry so that there is an additional column in all the tables "DTLS-OK?" or some such, and possibly 2) modifying TLS 1.2 spec IANA registration guidelines (i.e. what should the IANA requesters know about when they're making their request), and also possibly 3) asking IANA to ask future registrants about DTLS-OK feature if the requestor fails to do so on their own.

[Ballot discuss]
This is a fine document and I generally support its publication. However I have 2 minor issues which I would like to discuss before recommending approval of this document:

1). 7. IANA Considerations

  This document uses the same identifier space as TLS [TLS12], so no
  new IANA registries are required.  When new identifiers are assigned
  for TLS, authors MUST specify whether they are suitable for DTLS.

Does this mean that this document Updates [TLS12]?
Section 4.1.2.5 also confirms that.

2). I don't see a section "changes since DTLS 1.0" required by ID-nits. Can you convince me that it is not needed?

IANA has a question about the IANA Considerations in this document.

IANA understands that no new actions need to be completed upon approval
of this document. In the TLD HandshakeType registry located at:

http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-7

hello_verify_request is registered and the value "3" has been assigned
by the IANA.

IANA QUESTION: should the reference for this registration be updated to
[RFC-to-be]?

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:  (Datagram Transport Layer Security version 1.2) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'Datagram Transport Layer Security version 1.2'
  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 2010-12-14. 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.

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

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

(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?

Joe Salowey, working group co-chair, is the document Shepherd for this document. He has reviewed this version and believes it is 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 from key non-WG members. THe document shepherd has no concerns about the depth or breadth of the reviews.


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

The document shepherd does not have any specific concerns or issues with the document. There is an IPR disclosure,https://datatracker.ietf.org/ipr/1154/, which lists this document as related material. This disclosure has been discussed by the working group in relation to this and other documents such as 4366-bis.

(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 strong working group consensus around 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, there are some formatting issues, but these can be fixed by the RFC editor.

(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 references are split and OK. One reference needs to be updated.

(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 actions 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

This document specifies Version 1.2 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. This document updates
DTLS 1.0 to work with TLS version 1.2.

Working Group Summary

This document has been extensively reviewed int he working group.
There is strong consensus to move the document forward. The document
completed working group last call last year, but was delayed during the
discussion of other higher priority documents.

Document Quality

There are several vendors who implement DTLS 1.1. Vendors have indicated
they would support DTLS 1.2 to take advantage of AEAD cipher suites. The
document has ve reviewed by security and transport experts. The document
has been reviewed by implementers.

Posted related IPR disclosure: Certicom's Statement about IPR related to draft-ietf-tls-rfc4347-bis, draft-rescorla-tls-suiteb, draft-ietf-tls-extractor, draft-green-secsh-ecc, draft-ietf-avt-dtls-srtp, draft-igoe-secsh-suiteb, draft-ietf-smime-3851bis, draft-ietf-smime-3850bis, dra...

Posted related IPR disclosure: Certicom's Statement about IPR related to draft-ietf-smime-3278bis, draft-ietf-smime-sha2, draft-ietf-smime-multisig, draft-ietf-smime-3850bis, draft-ietf-smime-3851bis, draft-igoe-secsh-suiteb, draft-ietf-avt-dtls-srtp, draft-green-secsh-ecc, draft-ie...

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