IETF Logo Mail Archive

Re: [TLS] RFC 6066 - Max fragment length negotiation

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 18 March 2017 09:39 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4474D124BFA for <tls@ietfa.amsl.com>; Sat, 18 Mar 2017 02:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAFERkR2hmM6 for <tls@ietfa.amsl.com>; Sat, 18 Mar 2017 02:38:59 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12F612995B for <tls@ietf.org>; Sat, 18 Mar 2017 02:36:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1489829771; x=1521365771; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cFMloSb8NMpjD8BQhNRQ7rM0KhDAaFUG0I/tkj3wlQM=; b=z80B8kbLL+wixThH4ETVwI38HpiM7ULpd3BwpowBAyV7cj48GNdPY0jj +dgV5gnW25Tn7TFajwnZHUZ4CMwlPK+XcjoDf+8jKzcv+LKn7bLiLR1z3 t+4GjzB7YnFe+zRoVPLUzYFoHMHdpfzA3dIF+C3sOKc4p+fxwX4GccwA9 DYMLIRx6JBySR/bbKgu06+WV+VzWSgQY/dpI5C730CVHTayMg/KeD8FWF qxOBHbxnYdi0ffTjUG0Mja2yBV2qjprOKiNFHYJmYi6V4yrgDdh/6UyLU /Q5Ckwb/S2iOpXE+I5AZ4TyPjIzUn6jO3uwPAjAbmZYExg9dpfQ2/+47U A==;
X-IronPort-AV: E=Sophos;i="5.36,181,1486378800"; d="scan'208";a="143791600"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-c.UoA.auckland.ac.nz) ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Mar 2017 22:36:05 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.24) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 18 Mar 2017 22:36:05 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sat, 18 Mar 2017 22:36:05 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Joseph Birr-Pixton <jpixton@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] RFC 6066 - Max fragment length negotiation
Thread-Index: AQHSn8h48UgZsR1fnUWlpN1q8vk4DKGaVmu9
Date: Sat, 18 Mar 2017 09:36:05 +0000
Message-ID: <1489829754868.16595@cs.auckland.ac.nz>
References: <CACaGApnuePX7x4_4nj=z6=+xXbEyHRL9yr7TW96_yxVDo2eKkw@mail.gmail.com>
In-Reply-To: <CACaGApnuePX7x4_4nj=z6=+xXbEyHRL9yr7TW96_yxVDo2eKkw@mail.gmail.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rPa3ZZ1J6EZwD_5Ay0e5McHoRQg>
Subject: Re: [TLS] RFC 6066 - Max fragment length negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Mar 2017 09:39:01 -0000

Joseph Birr-Pixton <jpixton@gmail.com> writes:

>With the greatest of respect, mbedtls *doesn't* implement
>max_fragment_length[1], because it doesn't fragment handshake messages as
>required by the spec. Attempts to use it with a conforming peer will fail to
>handshake.

What's the largest handshake message it sends?  I would assume that for at
least the larger fragment sizes it'd be OK, because no handshake message would
get large enough to require fragmentation.

Incidentally, has anyone else who's implemented this dealt in the weird
omission of 8K by using the logical value 5 that follows 1, 2, 3, 4 for 512,
1K, 2K, and 4K?  In many cases 8K is just what you need, it halves memory
consumption while being large enough to not have to worry about fragmenting
handshake messages.

Peter.

v2.23.0 | Report a Bug | By Email