IETF Logo Mail Archive

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

Nitin Shrivastav <nitin.shrivastav@broadcom.com> Thu, 16 March 2017 23:35 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 65215129B63 for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 16:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 6tYRd_2d6If3 for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 16:35:33 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 6F079129A9B for <tls@ietf.org>; Thu, 16 Mar 2017 16:35:33 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id p77so43421925ywg.1 for <tls@ietf.org>; Thu, 16 Mar 2017 16:35:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UgA7jJGJz8SuHDIetyv7eOttJALFbFusZVfN7uIFqzc=; b=GmU3uMXs5qrXaVdma0Yp1cQXyNT7X/Oef40Fmlu++D8zicNjil1vI3gN1R5LgpAiZ7 cWrlDdLB3L6oNWsDXLef0AWv0y57S2UW2BIWnZbvd3NzDk3SvV1m8grFUmvbCce/Lyra MHz8xrcKD1ZM/bc5MHaRLWjbRqik4J0DpvBbU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UgA7jJGJz8SuHDIetyv7eOttJALFbFusZVfN7uIFqzc=; b=ZkSDkTA4iIub6dy9YRl6XhF0odfdBWL2UVx6SiVezm5nfQzAXZ65C7mre6l1bqx038 aDnkNmqUTUs8B+ptSKfG1NZKxK9+gPnXHRNSNEVnwC0YOh8KMn7ZRVb0wgtt/itAhatS xbVaHCYNEoTnipRteMSd1Yj8++ldXavz5Il+ZvYFrnAuKEOGWL//02F3+8Whznec9UDg 0hWW+ggsZTQ8pZWB/WcBohtVw9za7rlZkqcRzGpHtUoFzXge/uG+1wNLx6yWTVdD4TT/ 97gOVy/YEbgzss0cSYE9UC5ECrvTcxtbUYro2nTSh8OOLhEMlQK4Pt64r7HKm1mF8I8b LkuQ==
X-Gm-Message-State: AFeK/H2/rTI4k+v8Is2Y5xjm2SFLv78IL+SPTZjlEm5uedZN9FMWNrf90Z46NqkE3CVeRcIK
X-Received: by 10.129.82.196 with SMTP id g187mr609570ywb.89.1489707332543; Thu, 16 Mar 2017 16:35:32 -0700 (PDT)
Received: from ?IPv6:2602:304:cd81:1060:5849:6f84:6e28:92fb? ([2602:304:cd81:1060:5849:6f84:6e28:92fb]) by smtp.gmail.com with ESMTPSA id z194sm414406ywg.73.2017.03.16.16.35.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 16:35:31 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Nitin Shrivastav <nitin.shrivastav@broadcom.com>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <1489706298995.98317@cs.auckland.ac.nz>
Date: Thu, 16 Mar 2017 19:35:31 -0400
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <855C5079-FDA7-4E68-AE29-1E9605B495D7@broadcom.com>
References: <CAD8WAomJLs4hdaso9hT036=UORjT9=H5-oCHbdSofuv++n3rYg@mail.gmail.com> <1489706298995.98317@cs.auckland.ac.nz>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/moy_V7pleQbtuTKwtQE2pFKIJ_E>
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: Thu, 16 Mar 2017 23:35:35 -0000

Thanks Peter, seems like this extension is not an option.  I guess since our server is serving the web pages to browsers, we should be able to predict the max amount of data that will be pushed when user submits the data on the web page and tune the ssl buffer accordingly.

> On Mar 16, 2017, at 7:18 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> 
> Nitin Shrivastav <nitin.shrivastav@broadcom.com> writes:
> 
>> We don't have control over the clients in our scenario which are basically
>> the browsers like Chrome, IE etc.
> 
> I think a more important question would be "does any browser support this"?
> Looking at:
> 
> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
> 
> it seems like the answer is mostly "no".
> 
> Peter.
>

v2.23.0 | Report a Bug | By Email