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