Re: [TLS] I-D Action:draft-ietf-tls-rfc4366-bis-09.txt

Juho Vähä-Herttua <juhovh@iki.fi> Mon, 14 June 2010 13:26 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 02DD73A6801 for <tls@core3.amsl.com>; Mon, 14 Jun 2010 06:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.999
X-Spam-Level:
X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 S9cF8ryZsYQx for <tls@core3.amsl.com>; Mon, 14 Jun 2010 06:26:56 -0700 (PDT)
Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by core3.amsl.com (Postfix) with ESMTP id DEADD3A68D8 for <tls@ietf.org>; Mon, 14 Jun 2010 06:26:55 -0700 (PDT)
Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id o5EDQv8p007197 for <tls@ietf.org>; Mon, 14 Jun 2010 16:26:57 +0300
Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 20653-467 for <tls@ietf.org>; Mon, 14 Jun 2010 16:26:57 +0300 (EEST)
Received: from [130.233.194.236] (tko-add-236.cs.hut.fi [130.233.194.236]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id o5EDQlRj007158 for <tls@ietf.org>; Mon, 14 Jun 2010 16:26:47 +0300
Message-ID: <4C162E16.9090809@iki.fi>
Date: Mon, 14 Jun 2010 16:26: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: tls@ietf.org
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>
In-Reply-To: <516FD065-D91B-4281-8448-5C79FADDD69A@ll.mit.edu>
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
Subject: Re: [TLS] I-D Action:draft-ietf-tls-rfc4366-bis-09.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: Mon, 14 Jun 2010 13:26:57 -0000

14.6.2010 16:08, Blumenthal, Uri - 0668 - MITLL kirjoitti:
> It seems to me that Nikos is making a perfect point.
>    

Don't get me wrong, I'm mostly curious about the motivation behind 
adding larger values, because I think the benefit of it seems to be very 
small and originally I hadn't taken hardware decoding into 
consideration. After this discussion I think adding something like 2^13, 
2^15 and maybe (2^14 + 2^15) to the extension enum in question might be 
a good idea. Could add a specific notion that the implementation has to 
take care that it can support large fragments in case a value larger 
than 2^14 is accepted, because it is not required by the original 
specification. More efficient hardware decoding should be mentioned in 
motivation for accepting larger values as well, since now it only says 
memory and bandwidth constraings.

Not that it would be up to me to decide. :)


Juho