Subject: [Emu] Comment on 2716bis: TLS fragmentation

From: <[email-masked]>
Date: Mon, 6 Nov 2006 23:25:07 +0200

Section 2.1 contains a lot of text like "encapsulate one or more TLS
records in TLS record layer format, containing a TLS client_hello
handshake message."

RFC 2246 also says that "multiple client messages of the same
ContentType may be coalesced into a single TLSPlaintext record, 
or a single message may be fragmented across several records".

However.... in some testing I've done recently, I discovered that
fragmenting TLS handshake messages (as opposed to application data) 
is not really supported by current TLS implementations (I'm going to 
talk briefly about this in TLS WG on Friday).

Given that fragmentation is needed only with very long certificate
chains, a sane implementation (that wants to interoperate with others)
would not fragment any handshake messages unless they're longer than
2^14 bytes.

Maybe 2716bis should explicitly say that TLS handshake messages
MUST NOT (or possibly SHOULD NOT) be fragmented into multiple TLS
records if they fit in a single TLS record?

(Removing unnecessary complexity and unneeded options is in 
general a good thing, and I don't think we'd have backwards 
compatibility problems in this area.)

Best regards,
Pasi	

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 07 Nov 2006 08:32:18 -0800

On re-reading Section 2.3 on Fragmentation, I realized that it still 
contained some PPP-centric material (such as discussion of negotiation of 
PPP  Multilink MRRU).

Here is an updated section that hopefully addresses your comment:

"2.3.  Fragmentation

   A single TLS record may be up to 16384 octets in length, but a TLS
   message may span multiple TLS records, and a TLS certificate message
   may in principle be as long as 16MB.  The group of EAP-TLS messages
   sent in a single round may thus be larger than the MTU size or the
   maximum RADIUS packet size of 4096 octets.  As a result, an EAP-TLS
   implementation MUST provide its own support for fragmentation and
   reassembly.  However, in order to ensure interoperability with
   existing implementations, TLS handshake messages SHOULD NOT be
   fragmented into multiple TLS records if they fit within a single TLS
   record.

   In order to protect against reassembly lockup and denial of service
   attacks, it may be desirable for an implementation to set a maximum
   size for one such group of TLS messages.  Since a single certificate
   is rarely longer than a few thousand octets, and no other field is
   likely to be anywhere near as long, a reasonable choice of maximum
   acceptable message length might be 64 KB.

   Since EAP is a simple ACK-NAK protocol, fragmentation support can be
   added in a simple manner.  In EAP, fragments that are lost or damaged
   in transit will be retransmitted, and since sequencing information is
   provided by the Identifier field in EAP, there is no need for a
   fragment offset field as is provided in IPv4.

   EAP-TLS fragmentation support is provided through addition of a flags
   octet within the EAP-Response and EAP-Request packets, as well as a
   TLS Message Length field of four octets. Flags include the Length
   included (L), More fragments (M), and EAP-TLS Start (S) bits.  The L
   flag is set to indicate the presence of the four octet TLS Message
   Length field, and MUST be set for the first fragment of a fragmented
   TLS message or set of messages. The M flag is set on all but the last
   fragment.  The S flag is set only within the EAP-TLS start message
   sent from the EAP server to the peer. The TLS Message Length field is
   four octets, and provides the total length of the TLS message or set
   of messages that is being fragmented; this simplifies buffer
   allocation.

   When an EAP-TLS peer receives an EAP-Request packet with the M bit
   set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and
   no data.  This serves as a fragment ACK.  The EAP server MUST wait
   until it receives the EAP-Response before sending another fragment.
   In order to prevent errors in processing of fragments, the EAP server
   MUST increment the Identifier field for each fragment contained
   within an EAP-Request, and the peer MUST include this Identifier
   value in the fragment ACK contained within the EAP-Response.
   Retransmitted fragments will contain the same Identifier value.

   Similarly, when the EAP server receives an EAP-Response with the M
   bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS
   and no data. This serves as a fragment ACK. The EAP peer MUST wait
   until it receives the EAP-Request before sending another fragment.
   In order to prevent errors in the processing of fragments, the EAP
   server MUST increment the Identifier value for each fragment ACK
   contained within an EAP-Request, and the peer MUST include this
   Identifier value in the subsequent fragment contained within an EAP-
   Response."

-------------------------------------------------------------------
>From: <[email-masked]>
>To: <[email-masked]>
>Subject: [Emu] Comment on 2716bis: TLS fragmentation
>Date: Mon, 6 Nov 2006 23:25:07 +0200
>
>