IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Tue, 21 March 2017 23:59 UTC

Return-Path: <martin.thomson@gmail.com>
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 6A3DE1293E9 for <tls@ietfa.amsl.com>; Tue, 21 Mar 2017 16:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=gmail.com
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 NRqSChQ9F8B5 for <tls@ietfa.amsl.com>; Tue, 21 Mar 2017 16:58:58 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681C8128708 for <tls@ietf.org>; Tue, 21 Mar 2017 16:58:58 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id n21so143389438qta.1 for <tls@ietf.org>; Tue, 21 Mar 2017 16:58:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WkEoaJMOH5BDGFdlZtMoG+kUqEsGsQwc2T4BFr/4hec=; b=eHy9jj0qRcgx9mhvtrNf+Zihrn/SD6Y5x7d3K4mIj/2UZAvuIObd97ozjcWhl3Eg5W mH2nnGAnGqCAbNa57z69uspVeLEOE5Gwkp1FrJcw4fVigCx5IcHaMA/SiVW776SGs0i/ O7QV7lfWRL6nN/3DqDx8TJy8hR1OjMkFT06xnW23HG+bNnSVaV95nVMkIdfFdCOSwOTV HYg+Eryio6aOF8j9TwbW1D4rGB8FZPz4uUtc/DfAt2cr6x5H/b10Wl5L6jh+egsJTx50 fHxF6lnE94TrJ5bOREUWeP0R5jfQ87XzAdvHjRhKXq78uXnIy+rFPxNXi6yYuly0M/QX Djzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WkEoaJMOH5BDGFdlZtMoG+kUqEsGsQwc2T4BFr/4hec=; b=Z/47e8MZ+s96YF97FjPgLZDwp8DWOMcMXUjAeajMW17riHJjSvEwSXrEURmqhOKT3N MIbDyYMl0B5hzPIgJ19/Hof7bZHKznHs+NTWdwdaEhik4meiMHyYq56FZMZ80cwD2jsy zgQqgU2afHSpbAenjTVZL8Mb/T5K4FJuMf80trPrWr43ywOlnOTonY7bw2x39bdchp80 dQR0Dz3D6cS/UDx2DY/J1Uzfl5Ve4WZvXuSTy/EjUrfRa3N9pCvTcjtqf1eqEsibepOF 9Xmgeq/acemWjGCC0S5yI4w0u3KgFPXaVFLgAnvPpzBUWP+twRZCpV5jEnCnBY5T3xLr DuTg==
X-Gm-Message-State: AFeK/H3zwF8bGCXxo/h5mgHowcF/QygOS67mJWXBixJ3GHstA1hdEotbCi2HN6IFmzhGlFt3bMqq+jKwK/wnuw==
X-Received: by 10.237.51.5 with SMTP id u5mr38416990qtd.247.1490140737640; Tue, 21 Mar 2017 16:58:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.27.194 with HTTP; Tue, 21 Mar 2017 16:58:56 -0700 (PDT)
In-Reply-To: <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> <1490103123694.3164@cs.auckland.ac.nz>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 22 Mar 2017 10:58:56 +1100
Message-ID: <CABkgnnX1_YvbVb-FXjGe1jCuEjGxiaQ8WFuZGyuu0puNU+4ABQ@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Thomas Pornin <pornin@bolet.org>, "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MeVyZStCJbCcDM2ryKeawbhmYR8>
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 23:59:00 -0000

On 22 March 2017 at 00:32, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> 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.

Yep, you thought right.  I considered the same thing, investigated
what it would take to implement and found that it would be awful.  The
code that deals with record splitting doesn't know anything about the
specific cipher suite right now.  It would have to be taught about the
expansion, because without that information it would potentially send
a packet for encryption and then discover that it got too big in the
process and start over.  When compression is enabled, I can't imagine
what it would do.

Implementing a limit on pre-encryption data turns out to be pretty
trivial, because you change a constant (2^14) into a variable
(record_size_limit).

You are right that choosing the encrypted size makes setting the value
easier, but that moves the effort to the wrong place.  The constrained
device is the one that cares about this, so it can be the one to spend
the effort choosing the right value.  Move the effort somewhere else
and you will find that fewer non-constrained devices will bother
implementing the extension.

v2.23.0 | Report a Bug | By Email