IETF Logo Mail Archive

Re: [TLS] record layer limits of TLS1.3

Benjamin Kaduk <bkaduk@akamai.com> Mon, 28 November 2016 01:46 UTC

Return-Path: <bkaduk@akamai.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 55D8A127076 for <tls@ietfa.amsl.com>; Sun, 27 Nov 2016 17:46:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 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_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 7MWPpRxNKW9v for <tls@ietfa.amsl.com>; Sun, 27 Nov 2016 17:46:38 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id DC0BF12947A for <tls@ietf.org>; Sun, 27 Nov 2016 17:46:37 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 20B97433402; Mon, 28 Nov 2016 01:46:37 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 09947433401; Mon, 28 Nov 2016 01:46:37 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480297597; bh=B+YAWilAigSEmhA0xr8/V+HAj84k+GfWSoTlIro8820=; l=2333; h=To:References:Cc:From:Date:In-Reply-To:From; b=BdX8kpag22ASOe+sfkdYFs0TpZ9jqS45CZ22qxNpWHd4RZls2hvIAJmZ1xOvUrL4q +I+EUE/0MyL4Ue/WMadqVHupwWCcncS+ljd4GXczNgaeiMNDHSEsbhky5f80DeCBAg zyPjfs0eNHMkory4xPlvziegTGIi83QvraEgleKk=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id BD3E41FC90; Mon, 28 Nov 2016 01:46:36 +0000 (GMT)
To: Judson Wilson <wilson.judson@gmail.com>, Nikos Mavrogiannopoulos <nmav@redhat.com>
References: <1479884799.2563.3.camel@redhat.com> <B9F508E0-76F0-4252-AA24-38E3205F8BA9@gmail.com> <1479889806.2563.15.camel@redhat.com> <CAB=4g8+-2vZZ5qL6RfiKA73hHWxFV_QBQx_U7KZxZwGW=dO=oQ@mail.gmail.com> <1479890461.2563.20.camel@redhat.com> <CAB=4g8KwcYqEa+fO2rq56OAc7y_E7=i9Vy0_i6hDntgSh4URjA@mail.gmail.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <2d13cdf3-3596-332c-43ef-f3b16dc88798@akamai.com>
Date: Sun, 27 Nov 2016 19:46:36 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAB=4g8KwcYqEa+fO2rq56OAc7y_E7=i9Vy0_i6hDntgSh4URjA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------4238DFC16DB401E28774A741"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HJWonVL8SG7SsHTzZiMbbG5CgOY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] record layer limits of TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 28 Nov 2016 01:46:40 -0000

On 11/23/2016 02:46 AM, Judson Wilson wrote:
> I worry about the buffer sizes required on embedded devices. Hopefully
> the other endpoint would be programmed to limit record sizes, but is
> that something we want to rely on?  This could be a parameter agreed
> upon during the handshake, but that seems bad.
>

My understanding is that the original motivation (which admittedly
preceded me) included putting a cap on the amount of data that an
endpoint could be forced to buffer, yes.

Also note the proposal to steal the high bit of the length field to
indicate encrypted records, in the proposal to reclaim the three fixed
bytes from the record header. (https://github.com/tlswg/tls13-spec/pull/762)

-Ben

v2.23.0 | Report a Bug | By Email