Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-00.txt

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Sat, 19 June 2010 18:20 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 F0A3C3A6940; Sat, 19 Jun 2010 11:20:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.103
X-Spam-Level: *
X-Spam-Status: No, score=1.103 tagged_above=-999 required=5 tests=[AWL=1.193, BAYES_20=-0.74, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
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 jp6L1MiuG0dz; Sat, 19 Jun 2010 11:20:49 -0700 (PDT)
Received: from mail-n.franken.de (mail-n.franken.de [193.175.24.27]) by core3.amsl.com (Postfix) with ESMTP id 776483A67A7; Sat, 19 Jun 2010 11:20:48 -0700 (PDT)
Received: from [192.168.1.190] (p508FD667.dip.t-dialin.net [80.143.214.103]) by mail-n.franken.de (Postfix) with ESMTP id 74FFC1C0B4613; Sat, 19 Jun 2010 20:20:22 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="iso-8859-1"
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <094A6AB6-2E1B-41B8-A66B-BE4F907ED29E@iki.fi>
Date: Sat, 19 Jun 2010 20:21:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3CC809B6-CC7F-43EC-A5A9-16829990FC68@lurchi.franken.de>
References: <20100618201502.5F5763A6950@core3.amsl.com> <094A6AB6-2E1B-41B8-A66B-BE4F907ED29E@iki.fi>
To: Juho Vähä-Herttua <juhovh@iki.fi>
X-Mailer: Apple Mail (2.1081)
Cc: Internet-Drafts@ietf.org, tls@ietf.org, i-d-announce@ietf.org
Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-00.txt
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: Sat, 19 Jun 2010 18:20:50 -0000

On Jun 19, 2010, at 12:12 AM, Juho Vähä-Herttua wrote:

> On 18.6.2010, at 23.15, Internet-Drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Transport Layer Security Working Group of the IETF.
>> 
>> 
>> 	Title           : Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension
>> 	Author(s)       : R. Seggelmann, et al.
>> 	Filename        : draft-ietf-tls-dtls-heartbeat-00.txt
>> 	Pages           : 6
>> 	Date            : 2010-06-18
>> 
>> This document describes the Heartbeat Extension for the Transport
>> Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
>> protocol.
> 
> I have a small problem with the section 4 of the draft. First of all there it's written:
> 
> struct {
>    HeartbeatMessageType type;
>    opaque payload<0..2^14-5>;
>    opaque padding<0..2^14-5>;
> } HeartbeatMessage;
> 
> The length of payload and padding in total MUST NOT exceed 2^14-5
> bytes.
> 
> The notation "opaque payload<0..2^14-5>" is strange, usually this notation is used like "opaque payload<0..2^16-1>" which means "two length bytes followed by N data bytes". There is no common data type that would have a maximum value of "2^14-5", but there is a common data type with maximum value of "2^16-1", that is the unsigned 16-bit integer. Since the maximum total length of 2^14-5 is already explained in the following sentence, it should be no problem to change it as "2^16-1".
Looking at RFC 5246, section 4.3 I do not see any limitation on the array limits.
It is clearly stated how long the corresponding length field is. It is the
same for 2^14-5 or 2^16-1: It s two bytes.
> 
> Personally I would also consider storing the padding more like in GenericBlockCipher, with padding_length stored in the end of the message. It requires less space and is much easier to process in the implementation.
> 
> Another question is mostly curiosity, what's the motivation behind having padding if it is discarded later? I would also like to have instructions on what to do if a HeartbeatResponse message has padding with non-zero length. Right now it is not mentioned at all.
Hi Juho,

one application of the padding it to use Heartbeat messages for path MTU discovery.
I can send a test message of a particular size (by choosing the appropriate padding)
and get back a short ack. This way path MTU discovery works on asymmetric paths
without affecting user message transport. In particular this means that one need
padding which is longer than 255 bytes.

Best regards
Michael 
> 
> 
> Juho
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>