[TLS] RFC 6066 - Max fragment length negotiation

Nitin Shrivastav <nitin.shrivastav@broadcom.com> Thu, 16 March 2017 19:12 UTC

Return-Path: <nitin.shrivastav@broadcom.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 7320B12995A for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 12:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 MatR2fAfmuPH for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 12:12:22 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 9FFAD1296D4 for <tls@ietf.org>; Thu, 16 Mar 2017 12:12:22 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id u108so38600976wrb.3 for <tls@ietf.org>; Thu, 16 Mar 2017 12:12:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=vstKTLPyWKifEzSmzm7znCvSgMBQt96y6MRmu/V/3D0=; b=dd3nqID0NifDlxDRdm8Yb6VqfL2OBzaBoyz2hH904b2bfr0HcBFV5ULoclNCvx2h5f FoEsqQgdJj3EmSBNuB3Ws+RWJxyQ2TG1tnNwQA9grGJ8xgkI3rhuCTeeLhCOyeXAlLr6 VnbHa7N+DAFsZaH2ic1kn9/G+bIm4cz3sfVWA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vstKTLPyWKifEzSmzm7znCvSgMBQt96y6MRmu/V/3D0=; b=P8wEIZCXD9IXLUGw/ptTxj4RrsPiZVlwnAtyEmVBJ96HTy35f+q5/BIsmRLVAzo5vI VxkhYESysi9p555G3wLjGaBECzqU3yc0UxuTLWGrcUCHT5jrI9fduki70exK6hi3azDt HV2+rgFL+amyRRqutZc6zIBU5A1GMyBS2RNZuEtnpvnsTwmv8kuSxgBMb6BBPY2W0bqx q3PaUyekpq6u9Ev2UAv5L+WOY+7wzmsgpsxxMMMALXvFAyVCBsYTYod97EYd7Waz4hi8 VJ8KCUO8bnzVoqi0vrGjdDfxSNBWSulZ4NfkTLV1Zf+cEMnfPnLvl1yBH/i6wq2gurAG wTWA==
X-Gm-Message-State: AFeK/H26Pa5M3N6wEB8ZpFN8qvtKE3hpxs8Gg/JqkLysOq1bColDmJ9+n0BU7vBFWOj7A8ShendBbd8mbEZBGQly
X-Received: by 10.223.165.6 with SMTP id i6mr10346447wrb.18.1489691540984; Thu, 16 Mar 2017 12:12:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.55.141 with HTTP; Thu, 16 Mar 2017 12:12:20 -0700 (PDT)
From: Nitin Shrivastav <nitin.shrivastav@broadcom.com>
Date: Thu, 16 Mar 2017 15:12:20 -0400
Message-ID: <CAD8WAomJLs4hdaso9hT036=UORjT9=H5-oCHbdSofuv++n3rYg@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="f403045f1640203801054addd7e5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/l700Sq2m5nJDRfaS1VPk8w9sHKg>
X-Mailman-Approved-At: Thu, 16 Mar 2017 13:36:18 -0700
Subject: [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: Thu, 16 Mar 2017 19:13:37 -0000

Hello,

This is Nitin Shrivastav, Engineering Manager at Broadcom. I have a
question on RFC 6066 Maximum Fragment Length Negotiation section

The question i have is whether it is possible for a server to initiate the
Max fragment length negotiation. The RFC describes a scenario where a
constrained client can initiate this but in our product the server is very
tightly constrained on memory and we want to reduce the memory used for SSL
connections by forcing the clients to use reduce fragment length. We don't
have control over the clients in our scenario which are basically the
browsers like Chrome, IE etc.

Thanks,
Nitin