Re: [TLS] Record layer corner cases

On Tue, Nov 21, 2006 at 06:06:27PM +0200, Pasi.Eronen@nokia.com wrote:

> In San Diego I gave a short presentation on how various TLS
> implementations handle some corner cases in the TLS record protocol:
> 
> http://www3.ietf.org/proceedings/06nov/slides/tls-3.ppt
> 
> The conclusion was that receiving these corner cases is not handled
> well, probably because real implementations never send them.
> Thus, I'd suggest explicitly forbidding some of these corner
> cases in TLS 1.2. In particular:
> 
> - Implementations MUST NOT fragment Handshake, Alert, or Change
>   cipher spec messages to multiple TLS records unless the message 
>   exceeds the maximum fragment length (either 2^14 or negotiated 
>   with max_fragment_length extension).
> 
> - Implementations MUST NOT send zero-length fragments of Handshake, 
>   Alert, or Change Cipher Spec content types (zero-length fragments
>   of Application data would still be allowed; presumably they might
>   be useful against traffic analysis).
> 
> - Implementations MUST NOT send content types not defined in this
>   document except when explicitly negotiated using e.g. a TLS
>   extension (current text says unknown content types SHOULD
>   be just ignored).
> 
> - The maximum fragment size is a strict limit (i.e. change
>   "the length should not exceed 2^14" to MUST NOT).
> 
> Comments?

It seems to me that to avoid these problematic cases, "SHOULD NOT send
but MUST accept" is better than "MUST NOT send".

Can you describe the specific fragmentation strategies that you used
for testing?  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.)  If the very first handshake fragment
sent by the client contains at least six bytes to accommodate the
handshake message type (one byte), the message length (three bytes),
and the protocol version (two bytes), then things are much easier for
the server.  It's not fragmentation per se that should be a problem
for most implementations, just pathologically small fragmentation;
or so I hope.

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.

- 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.

Bodo

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls