[TLS] Record layer corner cases

<Pasi.Eronen@nokia.com> Tue, 21 November 2006 16:11 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYDT-0003RE-HH; Tue, 21 Nov 2006 11:11:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYDS-0003R1-DT for tls@ietf.org; Tue, 21 Nov 2006 11:11:22 -0500
Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYDQ-0004Y4-Vl for tls@ietf.org; Tue, 21 Nov 2006 11:11:22 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kALGAkRs031481 for <tls@ietf.org>; Tue, 21 Nov 2006 18:11:19 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 18:09:41 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 18:09:38 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 21 Nov 2006 18:06:27 +0200
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F24036EA3EE@esebe105.NOE.Nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Record layer corner cases
Thread-Index: AccNhwAmc2j+O0/aRu+KkwPWpYcf8w==
From: Pasi.Eronen@nokia.com
To: tls@ietf.org
X-OriginalArrivalTime: 21 Nov 2006 16:09:38.0090 (UTC) FILETIME=[719848A0:01C70D87]
X-Nokia-AV: Clean
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc:
Subject: [TLS] Record layer corner cases
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

Hi all,

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?

Best regards,
Pasi

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