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

Juho Vähä-Herttua <juhovh@iki.fi> Fri, 18 June 2010 22:12 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 6FC0F3A6936; Fri, 18 Jun 2010 15:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Few66E7a3Tmr; Fri, 18 Jun 2010 15:12:32 -0700 (PDT)
Received: from smtp-3.tky.hut.fi (smtp03.tky.fi [82.130.63.73]) by core3.amsl.com (Postfix) with SMTP id 091C73A6886; Fri, 18 Jun 2010 15:12:31 -0700 (PDT)
Received: from smtp.vaha-herttua.fi ([82.130.46.36]) by smtp-3.tky.hut.fi (SMSSMTP 4.1.9.35) with SMTP id M2010061901123513671 ; Sat, 19 Jun 2010 01:12:35 +0300
Received: from [192.168.1.121] (N243-60.surffi.net [80.247.243.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.vaha-herttua.fi (Postfix) with ESMTPSA id 7A7B61813D; Sat, 19 Jun 2010 01:12:35 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Juho Vähä-Herttua <juhovh@iki.fi>
In-Reply-To: <20100618201502.5F5763A6950@core3.amsl.com>
Date: Sat, 19 Jun 2010 01:12:34 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <094A6AB6-2E1B-41B8-A66B-BE4F907ED29E@iki.fi>
References: <20100618201502.5F5763A6950@core3.amsl.com>
To: Internet-Drafts@ietf.org
X-Mailer: Apple Mail (2.1078)
Cc: 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: Fri, 18 Jun 2010 22:12:33 -0000

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

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.


Juho