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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Sat, 12 June 2010 14:10 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
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 62AA13A69B6; Sat, 12 Jun 2010 07:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 FZYvPalsr-F9; Sat, 12 Jun 2010 07:10:06 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id EE8E63A68C4; Sat, 12 Jun 2010 07:10:04 -0700 (PDT)
Received: by wwc33 with SMTP id 33so1944306wwc.31 for <multiple recipients>; Sat, 12 Jun 2010 07:10:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=gyMNR/sXEukmRpVu3LSqe36D1XLRYG+vpldBh19qcg8=; b=HAe6Wq3AXO4RIJWmayXcNFA0upz1BPv8SKb8lT1Ee1x20+ZoKmAti7hLBOwxmTV9bm 5z9PaHGQZeKSpN0xgQ+NxEsjIxqh0gRqxdheNT/DXJKoqRHAcXAyHJCgVZvbS2CR0pvn F1eeZOLPM21NgsBJhnUuZRgKn3bZG81/3F1kc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=epU2vMZCp0JtF/JsomBvIGhRQYq7XbpEKzs3nDtpgNMZgLZGU3qcpXIl/XgKjrOJya hgBCVDEaege4HJX64qNtgQZ4OiDW1+a5RsVM1ayDU4G9iRV1BJvKHd0xP4r6CTgkash1 fcM1lKbqc0EuPJtiFwt1CyADfICV2xalT5qIA=
Received: by 10.227.127.85 with SMTP id f21mr3336077wbs.115.1276351803707; Sat, 12 Jun 2010 07:10:03 -0700 (PDT)
Received: from [10.100.2.14] (78-23-67-218.access.telenet.be [78.23.67.218]) by mx.google.com with ESMTPS id y31sm18780277wby.4.2010.06.12.07.10.02 (version=SSLv3 cipher=RC4-MD5); Sat, 12 Jun 2010 07:10:03 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4C13953A.8040107@gnutls.org>
Date: Sat, 12 Jun 2010 16:10:02 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Internet-Drafts@ietf.org
References: <20100612034512.CB07A3A687D@core3.amsl.com>
In-Reply-To: <20100612034512.CB07A3A687D@core3.amsl.com>
X-Enigmail-Version: 0.95.7
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 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: Sat, 12 Jun 2010 14:10:12 -0000

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) Extensions: Extension Definitions
> 	Author(s)       : D. Eastlake 3rd
> 	Filename        : draft-ietf-tls-rfc4366-bis-09.txt
> 	Pages           : 31
> 	Date            : 2010-06-11
> 
> This document provides specifications for existing TLS extensions. It
> is a companion document for the TLS 1.2 specification [RFC5246]. The
> extensions specified are server_name, max_fragment_length,
> client_certificate_url, trusted_ca_keys, truncated_hmac, and
> status_request.

It has been mentioned before, but I think its worthwhile to bring it up
again. The "Maximum Fragment Length" extension only allows setting a
fragment length that is lower than 2^14... Why not allow larger sizes
than that?


regards,
Nikos