[TLS] custom lower limit of record_size_limit

Daiki Ueno <dueno@redhat.com> Sat, 19 January 2019 08:02 UTC

Return-Path: <dueno@redhat.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 B444512EB11 for <tls@ietfa.amsl.com>; Sat, 19 Jan 2019 00:02:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 8RPQSA1Atl6t for <tls@ietfa.amsl.com>; Sat, 19 Jan 2019 00:02:48 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1026D12958B for <tls@ietf.org>; Sat, 19 Jan 2019 00:02:47 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0E57B5F74A for <tls@ietf.org>; Sat, 19 Jan 2019 08:02:47 +0000 (UTC)
Received: from localhost.localdomain (ovpn-116-93.ams2.redhat.com [10.36.116.93]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 315AE600C1 for <tls@ietf.org>; Sat, 19 Jan 2019 08:02:45 +0000 (UTC)
Message-ID: <87sgxpcbx8.fsf-dueno@redhat.com>
From: Daiki Ueno <dueno@redhat.com>
To: tls@ietf.org
Date: Sat, 19 Jan 2019 09:02:43 +0100
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Sat, 19 Jan 2019 08:02:47 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PEonr0nlMNumUVpw6bFgNlNjwpE>
Subject: [TLS] custom lower limit of record_size_limit
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 19 Jan 2019 08:02:50 -0000

Hello,

While RFC 8449 defines the minimum of record_size_limit as 64, if a
server takes account of the Security Consideration and chooses its own
lower limit (larger than 64), what should it behave?

   Very small record sizes might generate additional work for senders
   and receivers, limiting throughput and increasing exposure to denial
   of service.

In the beginning of section 4 (emphasis is my own):

   When the "record_size_limit" extension is _negotiated_, an endpoint
   MUST NOT generate a protected record with plaintext that is larger
   than the RecordSizeLimit value it receives from its peer.

and later in the same section:

   Endpoints SHOULD advertise the "record_size_limit" extension, even if
   they have no need to limit the size of records.  [...] _For
   servers, this allows clients to know that their limit will be
   respected._

My interpretation is that, if the client sent "record_size_limit" but
didn't receive the extension from the server, that would mean the
extension was not negotiated and the server may not respect the limit.

Is this correct, or 64 is really mandatory to implement?

Regards,
-- 
Daiki Ueno