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

Pekka Savola <pekkas@netcore.fi> Mon, 20 December 2010 13:13 UTC

Return-Path: <pekkas@netcore.fi>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5353A6897; Mon, 20 Dec 2010 05:13:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpMCs7Bai6xA; Mon, 20 Dec 2010 05:13:38 -0800 (PST)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 3678D3A6851; Mon, 20 Dec 2010 05:13:37 -0800 (PST)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id oBKDFKvM026505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Dec 2010 15:15:20 +0200
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id oBKDFIDV026501; Mon, 20 Dec 2010 15:15:19 +0200
Date: Mon, 20 Dec 2010 15:15:18 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: ietf@ietf.org
In-Reply-To: <20101130132359.32419.3777.idtracker@localhost>
Message-ID: <alpine.LRH.2.02.1012201513440.26448@netcore.fi>
References: <20101130132359.32419.3777.idtracker@localhost>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: clamav-milter 0.96.4 at otso.netcore.fi
X-Virus-Status: Clean
X-Mailman-Approved-At: Mon, 20 Dec 2010 10:10:23 -0800
Cc: tls@ietf.org, tls-chairs@tools.ietf.org, draft-ietf-tls-rfc4347-bis@tools.ietf.org
Subject: Re: [TLS] Last Call: <draft-ietf-tls-rfc4347-bis-04.txt> (Datagram Transport Layer Security version 1.2) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Dec 2010 13:13:40 -0000

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