Re: [TLS] Record layer corner cases
Bodo Moeller <bmoeller@acm.org> Fri, 24 November 2006 16:49 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GneFR-000256-JK; Fri, 24 Nov 2006 11:49:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GneFQ-00023h-9Y for tls@ietf.org; Fri, 24 Nov 2006 11:49:56 -0500
Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GneFO-0006xd-Or for tls@ietf.org; Fri, 24 Nov 2006 11:49:56 -0500
Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1GneFL3qDw-0004Zx; Fri, 24 Nov 2006 17:49:52 +0100
Received: by tau.invalid (Postfix, from userid 1000) id 533C24D9F; Fri, 24 Nov 2006 17:49:51 +0100 (CET)
Date: Fri, 24 Nov 2006 17:49:51 +0100
From: Bodo Moeller <bmoeller@acm.org>
To: Pasi.Eronen@nokia.com
Subject: Re: [TLS] Record layer corner cases
Message-ID: <20061124164950.GA28453@tau.invalid>
References: <20061121173346.GA15201@tau.invalid> <B356D8F434D20B40A8CEDAEC305A1F240371A720@esebe105.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F240371A720@esebe105.NOE.Nokia.com>
User-Agent: Mutt/1.5.9i
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
On Wed, Nov 22, 2006 at 02:53:33PM +0200, Pasi.Eronen@nokia.com wrote: > Bodo Moeller wrote: >> It seems to me that to avoid these problematic cases, "SHOULD NOT >> send but MUST accept" is better than "MUST NOT send". > This is very problematic for interoperability. If practically all > implementations follow the "SHOULD NOT send" (which they seem to do > today), the part about "MUST accept" never gets tested. This means > that even future implementations (at least those which care about > good interoperability) cannot violate the SHOULD NOT. > > And this is IMHO roughly where we are today... the spec has a feature > which nobody uses, and nobody can use. IMHO it would be better to > remove it, rather than leave it there "just in case". Well, for certificate chains that are "long" (compared to the maximum fragment length, or to some device's more limited maximum length for sending fragments), fragmentation is a feature that will be used. The minimum maximum fragment length (sic) is 2^9, so I suppose it would be reasonable to state that fragments of "handshake", "alert", and "change_cipher_spec" content type can't be empty and can't be smaller than 512 bytes unless they end where a message of the respective protocol ends. This does not rule out fragmentation within a message, but avoids pathological cases. >> Can you describe the specific fragmentation strategies that you used >> for testing? > I fragmented every handshake message (sent by the client) to two > fragments (split in the middle). I was asking because your observations do not agree with my earlier testing, which I repeated now: As far as I can determine, provided that the ClientHello and ServerHello messages are not pathologically fragmented, OpenSSL should not have problems with weird fragmentation. For my tests, except for Hello message fragmentation, I've used length-1 fragments and included the occasional length-0 fragment. So I'm not sure why you experienced problems with split-in-the-middle fragmentation unless you used some ancient software version. It seems possible that the implementation that you used for testing could be buggy, and that TLS servers don't really handle fragmentation as poorly as your observations indicate. >> I'd expect fragmentation to probably go wrong if it affects the very >> beginning of the TLS connection, when the server still has to decide >> which protocol version to use. (Support for the SSL 2.0 client >> hello format possibly makes this more complicated than it otherwise >> would have to be.) > Well, SSL 2.0 client hello can be distinguished from SSLv3/TLS hello > by looking at the first byte... Sure. However, things are more complicated if you have a mechanism intended to decide the protocol version among SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, etc. Without SSL 2.0 and without the SSL 2.0 client hello format, it would be easier because you could do the record handling outside the version-specific stuff. If you need to accomodate SSL 2.0 as well, then the record handling becomes version specific, and thus it may require additional effort if you need to join fragments before the protocol version has actually been chosen. >> For the first of the proposed restrictions (i.e., don't fragment >> unless the message exceeds the maximum fragment length), I think >> that even SHOULD NOT is too much: >> >> - First, consider implementations that collect multiple handshake >> messages before sending these in TLS records. The *total* length of >> these messages may exceed the maximum fragment length even if each >> *single* message is below the limit, and in this case we naturally >> would have a record boundary that is not aligned with the message >> boundary. > The restriction would apply only to TLS 1.2, and there aren't any > TLS 1.2 implementations yet... so we could even require that a single > fragment can't contain multiple handshake messages. It's still extra implementation work for implementations that don't happen to follow the potential new requirement. (At least they won't have to distinguish between protocol versions for this because the proposed behavior certainly is valid for SSL 3.0, and TLS 1.0 and TLS 1.1 as well.) Now that I come to think of it, if we want to change the words of the specification for TLS 1.2, we might just as well simply take the current description of fragmentation and add "And we mean it" ... :-) Seriously, if we rule out some odd cases of fragmentation, I don't think it is unreasonable to require all implementations to be able to properly process fragmented handshake messages. >> - Second, consider implementations designed to run with very little >> memory. These might be allowing large fragments when receiving >> data (since they can't rely on the max_fragment_length extension >> being universally available) but still be using smaller fragments >> when sending data. > Hmm... this is a valid argument, at least when the fragments are being > encrypted/MAC'd. What if the restriction (about not fragmenting unless > needed) only applied when current ciphersuite is NULL_WITH_NULL? My initial thought on this is that different rules for NULL_WITH_NULL and for other ciphersuites are an unnecessary complication. Also it probably would mean that the recipient-side handling of fragmentation wouldn't get tested as much as it otherwise could. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- RE: [TLS] Record layer corner cases Peter Williams
- [TLS] Record layer corner cases Pasi.Eronen
- Re: [TLS] Record layer corner cases Bodo Moeller
- Re: [TLS] Record layer corner cases Peter Gutmann
- Re: [TLS] Record layer corner cases Rob Dugal
- RE: [TLS] Record layer corner cases Pasi.Eronen
- Re: [TLS] Record layer corner cases Mike
- RE: [TLS] Record layer corner cases Pasi.Eronen
- Re: [TLS] Record layer corner cases Mike
- Re: [TLS] Record layer corner cases Martin Rex
- Re: [TLS] Record layer corner cases Peter Gutmann
- RE: [TLS] Record layer corner cases Peter Williams
- RE: [TLS] Record layer corner cases Peter Williams
- RE: [TLS] Record layer corner cases Peter Gutmann
- Re: [TLS] Record layer corner cases Bodo Moeller
- RE: [TLS] Record layer corner cases Peter Williams
- RE: [TLS] Record layer corner cases Kemp, David P.
- Re: [TLS] Record layer corner cases Martin Rex
- RE: [TLS] Record layer corner cases Peter Williams
- RE: [TLS] Record layer corner cases Kemp, David P.
- Re: [TLS] Record layer corner cases Mike
- Re: [TLS] Record layer corner cases Martin Rex
- RE: [TLS] Record layer corner cases Kemp, David P.
- Re: [TLS] Record layer corner cases Martin Rex
- Re: [TLS] Record layer corner cases Mike
- RE: [TLS] Record layer corner cases Peter Gutmann
- RE: [TLS] Record layer corner cases Peter Gutmann
- Re: [TLS] Record layer corner cases Kyle Hamilton
- Re: [TLS] Record layer corner cases Steven M. Bellovin
- Re: [TLS] Record layer corner cases Bodo Moeller
- Re: [TLS] Record layer corner cases Martin Rex
- RE: [TLS] Record layer corner cases Kemp, David P.
- Re: [TLS] Record layer corner cases Kyle Hamilton
- RE: [TLS] Record layer corner cases Peter Gutmann
- Re: [TLS] Record layer corner cases Bodo Moeller
- RE: [TLS] Record layer corner cases Pasi.Eronen
- Re: [TLS] Record layer corner cases Mike
- RE: [TLS] Record layer corner cases Kemp, David P.
- RE: [TLS] Record layer corner cases Kemp, David P.
- RE: [TLS] Record layer corner cases Peter Williams
- Re: [TLS] Record layer corner cases Martin Rex
- RE: [TLS] Record layer corner cases Peter Gutmann
- Re: [TLS] Record layer corner cases Martin Rex
- RE: [TLS] Record layer corner cases Peter Gutmann
- RE: [TLS] Record layer corner cases Kemp, David P.
- RE: [TLS] Record layer corner cases Pasi.Eronen
- Re: [TLS] Record layer corner cases Bodo Moeller
- Re: [TLS] Record layer corner cases Mike
- Re: [TLS] Record layer corner cases Bodo Moeller
- RE: [TLS] Diffie-Hellman parameters are unsigned … Pasi.Eronen
- Re: [TLS] Record layer corner cases Bodo Moeller
- RE: [TLS] Record layer corner cases Peter Williams