Re: [TLS] DTLS and large messages

Juho Vähä-Herttua <juhovh@iki.fi> Tue, 15 June 2010 09:07 UTC

Return-Path: <juhovh@iki.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 DFABF3A6A49 for <tls@core3.amsl.com>; Tue, 15 Jun 2010 02:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.049
X-Spam-Level:
X-Spam-Status: No, score=-4.049 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 xJJiO9Cn5CB3 for <tls@core3.amsl.com>; Tue, 15 Jun 2010 02:07:11 -0700 (PDT)
Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by core3.amsl.com (Postfix) with ESMTP id 5F5A23A67AC for <tls@ietf.org>; Tue, 15 Jun 2010 02:07:10 -0700 (PDT)
Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id o5F96pIn019555; Tue, 15 Jun 2010 12:06:51 +0300
Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 23539-845; Tue, 15 Jun 2010 12:06:50 +0300 (EEST)
Received: from [130.233.194.236] (tko-add-236.cs.hut.fi [130.233.194.236]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id o5F96m03019543; Tue, 15 Jun 2010 12:06:48 +0300
Message-ID: <4C1742A6.1050807@iki.fi>
Date: Tue, 15 Jun 2010 12:06:46 +0300
From: Juho Vähä-Herttua <juhovh@iki.fi>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: "t.petch" <ietfc@btconnect.com>
References: <E1ONiI8-0001C6-Ln@wintermute02.cs.auckland.ac.nz><4C149556.7040008@gnutls.org> <03826B11-ABC0-4F5B-A636-A07DECDF428C@iki.fi><AANLkTimYxYX8KqZ09bC-aglGU6D6W3JGH4gSlpmP4QCG@mail.gmail.com> <516FD065-D91B-4281-8448-5C79FADDD69A@ll.mit.edu> <00f301cb0c5b$f98cc2a0$4001a8c0@gateway.2wire.net>
In-Reply-To: <00f301cb0c5b$f98cc2a0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
Cc: tls@ietf.org
Subject: Re: [TLS] DTLS and large messages
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: Tue, 15 Jun 2010 09:07:13 -0000

15.6.2010 10:25, t.petch kirjoitti:
> How may an application send a 64kbyte (less headers) message over DTLS, assuming
> that the substrate is UDP and that UDP can carry 64kbyte datagrams without
> fragmentation?
>    

This sounds like another argument for max_fragment_length extension 
allowing lengths larger than 2^14...

> A usually reliable source has surprised me on two counts:
>
> First, I am told that when rfc4347-bis says
> "As in TLS
>         1.2, the length should not exceed 2^14.
> "
> then that is the authors' way of saying
> "As in TLS 1.2, the length MUST NOT exceed 2^14."
> which I had not guessed.
>    

That wording is indeed confusing and should probably be changed, TLS 1.2 
uses MUST NOT so a "should not" is not "as in TLS 1.2". With current 
wording I wouldn't recommend exceeding 2^14 length, since it is quite 
likely to break with some implementations.

> Second, that DTLS will break up the message into fragments of 2**14 or less but
> will then place them in a single UDP datagram so that they will transit the
> network as one, and can be safely reassembled at the far end.
>    

The specification says: "Multiple DTLS records may be placed in a single 
datagram. They are simply encoded consecutively." So in case of 64kB 
datagrams there can be either multiple complete records (with fragments 
of 2^14 or less) included in a single datagram or each record having its 
own datagram, in the receiving end both cases should be handled. It's 
basically the same as in TLS 1.2 where large handshake messages need to 
be fragmented into fragments of 2^14 or less and sent consecutively.

This is just my interpretation, but I think the specification is quite 
clear on this, and your source is probably correct.


Juho