ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-tls-rfc4347-bis-04.txt> (Datagram Transport Layer Security version 1.2) to Proposed Standard

2010-12-20 07:15:58
On Tue, 30 Nov 2010, The IESG wrote:
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'
 <draft-ietf-tls-rfc4347-bis-04.txt> as a Proposed Standard

A bit late to the IETF LC, but hopefully these are still useful.

This is an ops-dir review of draft-ietf-tls-rfc4347-bis-04 (DTLS 1.2).

This looks good, but the text seems a bit unclear on IP fragmentation vs
packetization. ICMP notifications passing up to the app is only a 'should'
and this begs the question why.  IANA considerations practicalities could
also be spelled out (not sure how detailed IANA wants these to be).

In more detail:

If I understand correctly *), initial DTLS exchanges will typically use
fragmented UDP packets due certificate sizes etc.  The likelyhood of
getting fragmented IP packets through firewalls and other devices is
significantly lower than getting UDP packets through.  The spec would be
more robust and the protocol likely more applicable in the face of
these 'network effects' if it tried to do packetization itself in such a
manner that IP fragmentation would not be necessary.

*) S 3.2.3 and 4.1.1 appear to be somewhat contradictory on this. See below.

The document does not have a "Changes from DTLS 1.0 (RFC4347)" section that
is is mandated or at least strongly recommended for update-specs.  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.

specific comments
-----------------

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.

   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.

.. is this too weak?  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.

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?
(This was triggered by S 4.1.2.5, so at least new Cipher Suites must
indicate this.)

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.

editorial
---------

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


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>