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

Juho Vähä-Herttua <juhovh@iki.fi> Sat, 19 June 2010 22:51 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 B2DA13A6981 for <tls@core3.amsl.com>; Sat, 19 Jun 2010 15:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Level:
X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=0.603, 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 ysNifU7BUDhX for <tls@core3.amsl.com>; Sat, 19 Jun 2010 15:51:50 -0700 (PDT)
Received: from smtp-3.tky.hut.fi (smtp03.tky.fi [82.130.63.73]) by core3.amsl.com (Postfix) with SMTP id 883353A694E for <tls@ietf.org>; Sat, 19 Jun 2010 15:51:49 -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 M2010062001515127854 ; Sun, 20 Jun 2010 01:51:51 +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 0EB921815C; Sun, 20 Jun 2010 01:51:51 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= <juhovh@iki.fi>
In-Reply-To: <2EC10EDD-E596-4C4B-8E1A-6A0745E4FDE9@lurchi.franken.de>
Date: Sun, 20 Jun 2010 01:51:51 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <49FD29DC-7FD5-4147-99B4-F9DA50B19C04@iki.fi>
References: <20100618201502.5F5763A6950@core3.amsl.com> <094A6AB6-2E1B-41B8-A66B-BE4F907ED29E@iki.fi> <AANLkTim5aw6SINvj0-E0X430G_QvFkazCRk39d-AvblH@mail.gmail.com> <C5CC73C4-E849-41B7-B337-F680910FB6F8@iki.fi> <2EC10EDD-E596-4C4B-8E1A-6A0745E4FDE9@lurchi.franken.de>
To: =?iso-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
X-Mailer: Apple Mail (2.1078)
Cc: tls@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 22:51:51 -0000

On 19.6.2010, at 22.39, Michael Tüxen wrote:
> uint8 is not enough as stated earlier.

I agree, the MTU detection requires large padding to make sure the actual reply gets through.

> What I do not understand is what you gain by putting the padding_length at the end?
> You do not save any space, I think. And it is also not complicated to use the
> format the ID currently describes. At least it was implementable in a pretty
> straight forward way in OpenSSL.

I don't like redundancy, and I like to have length variables in fixed locations if possible. It would also save 2 bytes to not store the payload length, wouldn't it? Based on the current ID I would implement the packet verification as follows:

1. read payload length
2. read padding length
3. verify that payload length + padding length is the same as TLSPlaintext.fragment_length-5

I also won't know the index of padding length before I've read the payload length first. If it would be stored like in block cipher padding I would do:

1. read padding length from the last 2 bytes
2. calculate payload length if necessary

In both cases I also have to check that TLSPlaintext.fragment doesn't go over 2^14 or the max_fragment_length, but I have to do that check anyway.

Of course both formats are ok, but I don't like to do step number 3, especially when the draft doesn't seem to say how I should react in case the lengths don't match. If there would be some more content, it would make more sense to store the both length values. But feel free to ignore me if you think my reasons are not good enough, I'm just trying to minimize the amount of error checking.


Juho