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

Martin Thomson <> Fri, 23 February 2018 01:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1B16126BF6; Thu, 22 Feb 2018 17:19:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J_UDbbQau7v6; Thu, 22 Feb 2018 17:19:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0EA5E12422F; Thu, 22 Feb 2018 17:19:21 -0800 (PST)
Received: by with SMTP id j81so3238800oia.0; Thu, 22 Feb 2018 17:19:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r0KWuIocE0v127Vap9UAAz8R+PCzVsoe9eQWglsBQxE=; b=CY7xQ+88k2TrVIsHzCE15ptrMcV1sZ1MMwIXANEdDJwNUtEGJ9OKfGNKyzwd75Owip uSMonBRPeCbWN9ys3CKWCC+IHpR6Yxb27ASGhN/wFGBIpEk0TNbAT1XmXi6unxYylB8q XYTn5MwmNiYoGOHpzbyqbyZ8fZBxlHiyx7zMmub6ymYErP+fwTtixKxRl2ZJa6lKWGBw L5cSFow2AypOsqlxHkKV4695M2z16Hpt/Jkl73+AMTdMZA5qeSbBk8lOdMhRAJ1GdhSo oPtzH3WOVPkQ5FzOFqXmBFtyVR/w6eG0KTHzxzahsFBz5oaeUWiz9aOjUeyqMJDMlZkC 1Z9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r0KWuIocE0v127Vap9UAAz8R+PCzVsoe9eQWglsBQxE=; b=p86TV/KT37E5JfCzOZB1sO4v508O5xn9o7vGNE1oyQauFK2LwEYihMLXfKZbRkb4Se EAdNSYdVpbrtZqr1l5mTYtkTFestUiS5uE+K83iQq1zFSjkqnNEqier6+bkVGI8FEidc M7NmGXydB0ueYj8HiaKsFVslFuxFRiGbIPsb9gEpgrsd1ZQz8yFlXf1SjjhRKSFdgOEO hEsHGyw2M+S2W+alSpQFn1qwGjSQhfHWIahNpDygXEsHybzCKqlIVQbtrlhqDeNUAyaH fOxZSji0vFOvBo4WxImP2APwr0B82cNYXhvPkk+LOi5SKmFlg3w+Y1fPhAq7ydupT9gg A8Ng==
X-Gm-Message-State: APf1xPBJKv/voiH1LL0Jq87/YWEjTJk0ORuZCdGWW3dwZ6vhfdtX9sfr jqj91zH5k+HpBFO2+z+NectLr7Df0ZGCEQOm/FY=
X-Google-Smtp-Source: AH8x227EySnr6zifmre2aMATxmK5R0wlJSfsg4OCVW0WUZg/2MiDvPABY8ulzJElDn+62KO+0IAoCJFkZJ068hfBLNU=
X-Received: by with SMTP id k4mr6153432oih.215.1519348760191; Thu, 22 Feb 2018 17:19:20 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 22 Feb 2018 17:19:19 -0800 (PST)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Fri, 23 Feb 2018 12:19:19 +1100
Message-ID: <>
To: Alan DeKok <>
Cc:, IESG <>,
Content-Type: text/plain; charset="UTF-8"
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 01:19:23 -0000

Thanks Alan,

A few changes based on your feedback here:

On Fri, Feb 23, 2018 at 9:21 AM, Alan DeKok <>; wrote:
>    In particular, it is not appropriate to use the record
>    size limit in place of path MTU detection.
> Q: How would that be done?  I don't mean that the document needs to explain how to do something wrong.  I mean that it would be good to explain the misunderstanding which would lead to using record size limit in place of path MTU detection.

How would you mess this up?  Set record_size_limit to your MTU with
the expectation that this is sufficient.  Worse, the expectation that
peer has also done this.

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.

> 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

+The path maximum transmission unit (PMTU) in DTLS also limits the size of
+records.  The record size limit SHOULD be set independently of PMTU.  The
+record size limit is fixed during the handshake and so is best set based on
+constraints at the endpoint and not the current network environment.  In
+comparison, the PMTU is determined by the network path and can change
+dynamically over time.  See {{?PMTU=RFC8201}} and Section of {{?DTLS}}
+for more detail on PMTU discovery.

> Comment: the registry has no "status" column.

Ahh, a problem of concurrent updates.
draft-ietf-tls-iana-registry-updates (which is going out just ahead of
this) adds that column.  I don't think that there was any intention of
creating an explicit dependency, which won't make sense in 5 years
time, but I guess we can add an informational reference.