IETF Logo Mail Archive

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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 21 March 2017 13:32 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 9FDDC120727 for <tls@ietfa.amsl.com>; Tue, 21 Mar 2017 06:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 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, URIBL_BLOCKED=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 qAz25NfSAISm for <tls@ietfa.amsl.com>; Tue, 21 Mar 2017 06:32:10 -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 1C26C1298A6 for <tls@ietf.org>; Tue, 21 Mar 2017 06:32:09 -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=1490103130; x=1521639130; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nctVDfxu7OiNEuNifAh4SWzTmUyJFKsf1cOQvKWWnoM=; b=SYrqibCGezRsJ/OM7qPpX7thLLFB/70MfnKHseWh4m1fR65fo70g63U8 E4Sf0TYe3H8gvn2SDlW0mHQXzNwU49qxxNfrwWjexaRR2vDfxBDiW+1yD 85t+ZVLJLhgfZ3DKL6cErL8aLA9D4H8LCP9wBvdJtkpS6J6oxBexa85Jp wzfvlsM92olMLeMVNPblOZ07JowdMfEziStKQs79LzDVZBNX7u7KZ86S+ OzWa+OuawnNkGYIT+0VZjf3E68tEJyXRAAyCZ+1zLeeFlloYI/WQm7Lq+ cukmyGbanwmk5QM2KqZoUR4GDAvrD37nCgQ7xU9yErlN46mGVHlxSuLIx Q==;
X-IronPort-AV: E=Sophos;i="5.36,198,1486378800"; d="scan'208";a="144490102"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing
Received: from uxcn13-tdc-c.uoa.auckland.ac.nz ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Mar 2017 02:32:07 +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.4) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 22 Mar 2017 02:32:07 +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; Wed, 22 Mar 2017 02:32:07 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Thomas Pornin <pornin@bolet.org>, Martin Thomson <martin.thomson@gmail.com>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] RFC 6066 - Max fragment length negotiation
Thread-Index: AQHSnpUB8UgZsR1fnUWlpN1q8vk4DKGYGe7w//8q+oCAANxgO///LA8AgADcRWz//0AsAAAe+X57//8qVYCAACsrgIAGvC4AgADelwI=
Date: Tue, 21 Mar 2017 13:32:06 +0000
Message-ID: <1490103123694.3164@cs.auckland.ac.nz>
References: <CAD8WAomJLs4hdaso9hT036=UORjT9=H5-oCHbdSofuv++n3rYg@mail.gmail.com> <1489706298995.98317@cs.auckland.ac.nz> <855C5079-FDA7-4E68-AE29-1E9605B495D7@broadcom.com> <1489707933992.42551@cs.auckland.ac.nz> <CABkgnnVRZBwXHZ6w=gX9pykNpXp80OLP1pe-VMg-uO-C6O8yEQ@mail.gmail.com> <1489710142144.88978@cs.auckland.ac.nz> <CABkgnnXiB5ksGbbPqDP3D=FVdQu9ht0vD8-T-5HTaEKQQE4+9w@mail.gmail.com> <1489721710740.52293@cs.auckland.ac.nz> <CABkgnnWq_5e8TJgJV+okqi6vo-_5=811pOZRtUCp0TD07SmNoQ@mail.gmail.com> <CABkgnnW=Pz+6M8UYoB+MTY8rQp9vsHyh6aqiSb3EbTT_BdWokA@mail.gmail.com>, <20170321131514.GA9342@bolet.org>
In-Reply-To: <20170321131514.GA9342@bolet.org>
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/Goub9LAE6_5i1Uli8wu8sm4KqLM>
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: Tue, 21 Mar 2017 13:32:13 -0000

Thomas Pornin <pornin@bolet.org> writes:

>Maybe there should be some extra wording saying that when a "maximum record
>size" was received, with a value less than the protocol-defined limit, then
>an endpoint SHOULD strive to use minimal-sized padding in cipher suites that
>have a variable-sized padding.

I'd earlier thought of suggesting that the record length be the ciphertext
length, not the plaintext length, but wasn't sure if there'd be much support
for it.  It would however certainly make the required calculations easier,
since you no longer have to figure out what the potential size could be once
you've added the MAC size, padding, and anything else that needs to go in,
particularly since some of those factors are variable-length, leading to
guesswork as to what you need to specify since some of the parameters won't be
fixed at the time you ask for record size X.

Peter.

v2.23.0 | Report a Bug | By Email