Re: [secdir] Secdir review of draft-ietf-tls-record-limit

Benjamin Kaduk <> Fri, 23 February 2018 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04E971241F3; Fri, 23 Feb 2018 11:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aIPb6XHRuSpM; Fri, 23 Feb 2018 11:17:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18F361205F0; Fri, 23 Feb 2018 11:17:24 -0800 (PST)
X-AuditID: 1209190f-81bff70000005fde-fc-5a9068c28737
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 57.DE.24542.3C8609A5; Fri, 23 Feb 2018 14:17:23 -0500 (EST)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w1NJHI8Q032473; Fri, 23 Feb 2018 14:17:20 -0500
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id w1NJHE6j014966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Feb 2018 14:17:17 -0500
Date: Fri, 23 Feb 2018 13:17:14 -0600
From: Benjamin Kaduk <>
To: Alan DeKok <>
Cc: Martin Thomson <>,, IESG <>,
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IRYrdT1z2cMSHKYPJbM4umz03sFvvP8FjM +DOR2eLamX+MFh8WPmRxYPVoOdrC4rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZew+dpep 4Bx/xZ/VV9gaGNfwdDFyckgImEh8b1/N2MXIxSEksJhJYuXNXkaQhJDARkaJr9vzIRJXmSRm rPvLCpJgEVCVeLBrBguIzSagItHQfZkZxBYR0JJYsH4RC0gDs0APo8T2O9PBEsIClhI3pp1m A7F5gdbtmHGRDWLqKUaJGUsOskIkBCVOznwCNpUZaNKNfy+Zuhg5gGxpieX/OEDCnALuEn1f TzCB2KICyhJ7+w6xT2AUmIWkexaS7lkI3QsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpmujl ZpbopaaUbmIEhTOnJP8OxjkN3ocYBTgYlXh4I8QnRAmxJpYVV+YeYpTkYFIS5Y2yAArxJeWn VGYkFmfEF5XmpBYfYpTgYFYS4S173h8lxJuSWFmVWpQPk5LmYFES53U30Y4SEkhPLEnNTk0t SC2CycpwcChJ8J5KBxoqWJSanlqRlplTgpBm4uAEGc4DNNwCpIa3uCAxtzgzHSJ/ilGX48aL 123MQix5+XmpUuK8d9KAigRAijJK8+DmgNKQRPb+mleM4kBvCfN+BBnFA0xhcJNeAS1hAlpy gasXZElJIkJKqoFx06IaKx6X7T2li5Z6PrmX313brON0KmS5kVbHoRcxfMJXlGI+Vm+e4Put vPrkncXLYlczvUrVVmm/b603/Yx40+OqXIs/s/VWLE03OWH/7hjb1D5p9f9GG/Z33ej8vNUs unBHcGuD0G3rhQkv2IpmP9f32GdXqRDtrtivrSgdILQ7+/59Y2clluKMREMt5qLiRAB//f6A HgMAAA==
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-tls-record-limit
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Feb 2018 19:17:27 -0000

On Fri, Feb 23, 2018 at 09:49:11AM -0500, Alan DeKok wrote:
> On Feb 22, 2018, at 8:19 PM, Martin Thomson <>; wrote:
> > A few changes based on your feedback here:
> >
>   Thanks. That helps.
> > The remainder of the paragraph is intended to make that distinction
> > clear.  i.e., this limit is inherently fixed by negotiation, the other
> > is dynamic.
>   My point is that those two limits may agree or disagree dynamically.  So it would be good to give guidance on what to do when a previous agreement dynamically changes to disagreement.
> >> Comment:  it would be good to give guidance on what to do here, and what happens in error cases.
> > 
> > DTLS (RFC 6347) already has some fairly extensive guidance on PMTUD,
> > which I didn't want to replicate here.  You hit a lot of the issues in
> > your questions.  With some better citations, this is what I came up
> > with:
>   That still doesn't give guidance.  What happens if the record size limit is fine at the start of a session, and then MTU changes, and the packets no longer make it through?   What does the application do?
>   RFC 6347 Section gives some guidance, but I think not enough.  Exposing the MTU to the application is good, but what does the application *do* with this information?
>   e.g. PMTU should be exposed to the application as per Section of {{?DTLS}}.  If the PTMU changes, the application may discover that the new MTU is smaller than the record size limit.  In that situation, the only recourse available may be to close the session, and to open a newer one with a smaller record size limit that is compatible with the new MTU.

The record size limit is a cap, not a mandatory record size.  So,
the application could just send smaller records that fit within the
new PMTU, provided both sides have the proper logic around PMTU
discovery and record sizing.