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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sun, 13 June 2010 08:11 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 44E463A68C7; Sun, 13 Jun 2010 01:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.767
X-Spam-Level:
X-Spam-Status: No, score=-0.767 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_50=0.001]
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 1Or5JMsm8oj1; Sun, 13 Jun 2010 01:11:53 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id D44053A688E; Sun, 13 Jun 2010 01:11:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1276416717; x=1307952717; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20juhovh@iki.fi,=20nmav@gnutls.org|Subject:=20Re:=20 [TLS]=20I-D=20Action:draft-ietf-tls-rfc4366-bis-09.txt |Cc:=20i-d-announce@ietf.org,=20Internet-Drafts@ietf.org, =20tls@ietf.org|In-Reply-To:=20<D094D406-40A5-4DA0-8EB7-A 18FFA91BC15@iki.fi>|Message-Id:=20<E1ONiI8-0001C6-Ln@wint ermute02.cs.auckland.ac.nz>|Date:=20Sun,=2013=20Jun=20201 0=2020:11:40=20+1200; bh=qlguooZkrrvnXgddwVcqAQi2hE1YEQK1dzbnhCKO2fM=; b=ojbFVFitfWZxnZsAF+EwBuVIw34ZQQ7HSi184FF+FgyH8gFGJulFRYu7 R4OEt2xi4+yNRFY0NvwDnyBnv0eagd+zdlJd/6b8Cn9D+sJ050HwxFRh9 Lb7BhOX5s/AXwyqgdswSHZ5Ora9lYtiWOL3adAkGoEbVfpnglRBLwue/r o=;
X-IronPort-AV: E=Sophos;i="4.53,410,1272801600"; d="scan'208";a="10850789"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing
Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Jun 2010 20:11:40 +1200
Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@cs.auckland.ac.nz>) id 1ONiI8-0001C6-Ln; Sun, 13 Jun 2010 20:11:40 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: juhovh@iki.fi, nmav@gnutls.org
In-Reply-To: <D094D406-40A5-4DA0-8EB7-A18FFA91BC15@iki.fi>
Message-Id: <E1ONiI8-0001C6-Ln@wintermute02.cs.auckland.ac.nz>
Date: Sun, 13 Jun 2010 20:11:40 +1200
Cc: Internet-Drafts@ietf.org, tls@ietf.org, i-d-announce@ietf.org
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: Sun, 13 Jun 2010 08:11:58 -0000

Nikos Mavrogiannopoulos <nmav@gnutls.org> writes:

>I have no exact information about where 2^14 the limit itself is coming from 
>(it dates all the way back to SSL 3.0), but I can imagine it has something to 
>do with values 2^15 and up being negative if signed 16-bit integers are used. 

It may also have been because it's a convenient upper bound for memory 
buffers, particularly in embedded systems.  There's an awful lot of SSL 
running in little controller boards for various devices, having to allocate 
potentially 2 x 64kB buffers (the limit for 16-bit lengths) instead of 2 x 
16kB would have been a deal-breaker for some of them.  In addition, as you
say, on 16-bit systems (some of which are still in use today, again in 
embedded devices) you run into risky conditions once you get close to 2^15.

Peter.