IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Fri, 17 March 2017 00:05 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 2A49A129B74 for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 17:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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] 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 XACP4ZydXX3A for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 17:05:44 -0700 (PDT)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 06BB8129A54 for <tls@ietf.org>; Thu, 16 Mar 2017 17:05:44 -0700 (PDT)
Received: by mail-qt0-x22a.google.com with SMTP id i34so51607656qtc.0 for <tls@ietf.org>; Thu, 16 Mar 2017 17:05:43 -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=3MaEsjT0dX4XwhmT33jUHBUidDyyPibXkI12P6uDFEE=; b=HDYD5Y7bL+ldfdaNudA1SDN1EUGAijOK45MUjQ0YMGbDrP7/NpO/t2dOczcQ+4Ljjx W/R1xhGRBK5KcxLgz37g+olbAeyTsako/dPGYIl6oG4iVHLRHvcufo0pGr3SL75HNqOf mBOvd7n34/N6e9q6Kis5oQei+7AnVgYTyrT+CfRlKNpFN2SvnEG8YRq1b94Cz4qsPFiA DlzNMhcVhKKAcWP4tb+kaywRwMKP6HLNtsOu5WrclidVFUWSluZIHd00UFyEnOtF+pTx ryVnGaWArgM061CnGri1iMhPjRr1xEYpoicj5TV0TvIkE/XPuUcFmmmucJ3yfK210/Xm Y0VQ==
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=3MaEsjT0dX4XwhmT33jUHBUidDyyPibXkI12P6uDFEE=; b=bCLLqvbxZTYUfOAUXKoHafhpC0oO2EAEJudpXS0NmJkIjyWGf/caDAD+cy58WZCf0F LKRfPquFwFYC6//7lArHQc4e/wNlzjXGScpCwhs864eWmKsdof6Q2H4zHMCQROkP4faH n7tiSoclFfI3AxKwMNiOa7iYk2FXtgbC90ZOd8v+JKpqJ5jhmrGd7cgwJRZRLRPvrV0w puq1LLC6qiAX+xS+jnKF/Xv4SEc1m/7soZri+6Cy+OguyCyWbadJ2IvGS5IgbLDAZUeA HTwY/pjw0FrptFA6lWHdXaisVyhOlyer0XR0kfJkkBj+67K1enJq8X/2ooi/CxDLMNOn SF4g==
X-Gm-Message-State: AFeK/H3H2SJwx5DlEqtOADy6XKD8dPNVy12s89l0z0NzY20kdV92s2gIiQ1RVIFvNNWmFr5l7ozrSeKnEcVE3g==
X-Received: by 10.237.51.5 with SMTP id u5mr12316368qtd.247.1489709143117; Thu, 16 Mar 2017 17:05:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.27.194 with HTTP; Thu, 16 Mar 2017 17:05:42 -0700 (PDT)
In-Reply-To: <1489707933992.42551@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>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 17 Mar 2017 11:05:42 +1100
Message-ID: <CABkgnnVRZBwXHZ6w=gX9pykNpXp80OLP1pe-VMg-uO-C6O8yEQ@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Nitin Shrivastav <nitin.shrivastav@broadcom.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iwcAhcDURIv4XM0e5ucJMZrPPUE>
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: Fri, 17 Mar 2017 00:05:45 -0000

On 17 March 2017 at 10:45, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
>
> In which case it might be time to update the RFC, since there's no obvious
> reason why you can't send it from the server.  Can any of the original authors
> provide a reason why it shouldn't be done by the server?

Most clients will explode if the server sends an extension that the
client didn't offer.

You would have more luck getting clients to implement the extension.
I looked at this, and it's not impossible.  The spec contains some
frightening things in it though.

v2.23.0 | Report a Bug | By Email