Re: [TLS] draft-ietf-tls-rfc4347-bis-00.txt
Eric Rescorla <ekr@networkresonance.com> Tue, 14 October 2008 10:46 UTC
Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321653A6A50; Tue, 14 Oct 2008 03:46:44 -0700 (PDT)
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 13FCE3A67EA for <tls@core3.amsl.com>; Tue, 14 Oct 2008 03:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.535
X-Spam-Level:
X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 lt44QqzwAIOE for <tls@core3.amsl.com>; Tue, 14 Oct 2008 03:46:42 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 461183A6A50 for <tls@ietf.org>; Tue, 14 Oct 2008 03:46:42 -0700 (PDT)
Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id BEA426C3D3F; Tue, 14 Oct 2008 03:46:57 -0700 (PDT)
Date: Tue, 14 Oct 2008 03:46:57 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Robin Seggelmann <seggelmann@fh-muenster.de>
In-Reply-To: <3D67B0D0-BFE2-4DFF-A847-C4BF3BFCE08E@fh-muenster.de>
References: <3D67B0D0-BFE2-4DFF-A847-C4BF3BFCE08E@fh-muenster.de>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20081014104657.BEA426C3D3F@kilo.rtfm.com>
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-rfc4347-bis-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-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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org
At Tue, 14 Oct 2008 10:04:37 +0200, Robin Seggelmann wrote: > > Hello all, > I was just checking the draft for changes relevant to DTLS over SCTP > and came across the following new paragraph: > > - For DTLS over TCP or SCTP, which automatically fragment > and reassemble datagrams, the upper layer protocol > SHOULD be informed that the PMTU is effectively infinite. > > What does 'effectively infinite' mean? TLS limits the message size to > 2^14 bytes, so shouldn't this limit also apply to DTLS? If the > message size really is arbitrary, doesn't this affect some cipher > algorithms? Or should the application then ignore the announced > 'infinite' PMTU and limit the message size anyway? Yes, that's a fair point. OTOH, this is a maximum message size which is related to, but not identical to, the PMTU. Operationally the application needs to restrict itself to 2^14 and associated limits. I'm tempted to simply add a parenthetical "(though of course applications still MUST NOT write any record that exceeds 2^14 bytes)" -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- [TLS] draft-ietf-tls-rfc4347-bis-00.txt Robin Seggelmann
- Re: [TLS] draft-ietf-tls-rfc4347-bis-00.txt Eric Rescorla
- Re: [TLS] draft-ietf-tls-rfc4347-bis-00.txt Michael Tüxen
- Re: [TLS] draft-ietf-tls-rfc4347-bis-00.txt Eric Rescorla
- Re: [TLS] draft-ietf-tls-rfc4347-bis-00.txt Michael Tüxen