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

Alan DeKok <> Fri, 23 February 2018 14:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62EF8127337; Fri, 23 Feb 2018 06:49:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J47junh1KSmV; Fri, 23 Feb 2018 06:49:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5B4C01270A3; Fri, 23 Feb 2018 06:49:14 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 2FA9D1FE8; Fri, 23 Feb 2018 14:49:13 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan DeKok <>
In-Reply-To: <>
Date: Fri, 23 Feb 2018 09:49:11 -0500
Cc:, IESG <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3124)
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 14:49:16 -0000

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.

  Alan DeKok.