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

Martin Thomson <> Mon, 26 February 2018 01:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8FA81273B1; Sun, 25 Feb 2018 17:31:48 -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 7ss0Kr489CYu; Sun, 25 Feb 2018 17:31:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 528971271FD; Sun, 25 Feb 2018 17:31:47 -0800 (PST)
Received: by with SMTP id j79so9515181oib.12; Sun, 25 Feb 2018 17:31:47 -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=RDdwhU2awrnO8FcKYTTNthurUQVe3WQQbd6YT8IKmgw=; b=KzWv9yHDcM9LK47CipLhWjXA6Bmk1CAU7mMTzsUc2zbuFa7y01YLZCZ/dJAfBVgi0m audGk1qp9P4tb+LvJWZu6pNu5z99aZJJQKc7lFRJnR2qAJHkphpB3dXUoqYA0SLrTEEC 3f5HhWWQehGr5d890hTMHtgZwELgXCe6TiM/bNnfxTsi9PxrK4v7n2Oeq+lsdy5uQWsd DYO4iQ9OpZKXKEvKjVyGL0uMA8Ui4OPZBMOTV67xux0h+OUntJNgUGMeP4HhkB347PCe UKnEzychb7b6QGgyPKwVORAF0XCDpqAkuioTFJrNzeybZln2YirNy7W5oEPgfePR+v35 G6Pg==
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=RDdwhU2awrnO8FcKYTTNthurUQVe3WQQbd6YT8IKmgw=; b=ee6pJpxytUKRxkEt4XtzL8YXevBEcKGKc4lyf3R8SQEuXJdJAPv75vrP6LNHOe5kaf 13pX7NVHxSxJJFm15XgSd77lwkSX+GYLuo7o/Ge+D5g22ihEQRwH8LRcHsUA4IlxYTDJ Zo1jJXdWHKPPGfHiZ7Va6SRWXbCq/8CzLAeXIJDJ5t2ur97Xn46tvjZdjb4DW4F4da9B +G2kGafNDzbUsB0FMvt+YhPz23kRwnlCGfpR/o2zbcI7qoj1Sc67Bxwj1I3OtQ3FPaPw nOGUmhx/nwkJoObCICwouagKcmHHCPFZQ2niZOORYe76V5DlqwMIAOhhFw/c08kWDo+m ILhQ==
X-Gm-Message-State: APf1xPDBmxHInjmFSBfQp9IPiNzuAKftS/vDnVW/6mMdRI63uLMrkq7y aVPIhcjMnDqDKTpx1qDftfJl4/cUaFplPlZo8EAA2Tg/
X-Google-Smtp-Source: AG47ELuZ/oqftAGCQEWDSlUkkOzvicCG3MnTZFXwrzN5yX85T+qgBJJOW0bX/sA5RuIRdqOsl5+Nl1wid5Zf2HQIsrQ=
X-Received: by with SMTP id j127mr5744504oih.346.1519608706461; Sun, 25 Feb 2018 17:31:46 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 25 Feb 2018 17:31:45 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Martin Thomson <>
Date: Mon, 26 Feb 2018 12:31:45 +1100
Message-ID: <>
To: Benjamin Kaduk <>, Hannes Tschofenig <>
Cc: Alan DeKok <>,, 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: Mon, 26 Feb 2018 01:31:49 -0000

On Sat, Feb 24, 2018 at 6:17 AM, Benjamin Kaduk <>; wrote:
> The record size limit is a cap, not a mandatory record size.

That's right.  Alan, does that address your primary concern?

> On Fri, Feb 23, 2018 at 09:49:11AM -0500, Alan DeKok wrote:
>>   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?

In many cases, nothing.

My understanding of DTLS implementations is that the size of a write
determines the size of the packet that is ultimately sent.  Say I
write 100 octets to the socket, so DTLS writes out a record of 128

What stacks do when a write exceeds PMTU differs.  The same applies to
this new limit:

* The stack I work on splits records based on its understanding of the
MTU, but it only learns that during the handshake and so relies mostly
on the application making smaller writes.  (There is currently no way
to set the MTU, which is an open bug.)  It also sends a single record
in each packet for application data, so the net effect of a large
write is multiple UDP datagrams with one record each.

If your stack operates like this, then the information is pretty much
just advisory.  The only thing you might contemplate is changing any
coalescing rules you might have to compensate.

* If a stack did automatic splits, but then put multiple records in
the same datagram, that's the same for a using application.

* If a stack rejects large writes and forces the application to write
within its constraints, then that stack needs to be clear about what
limit was in force, such as through the use of specific error codes.
Such stack that adds this feature would need to be careful about
introducing this feature.