[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
- [TLS] custom lower limit of record_size_limit Daiki Ueno
- Re: [TLS] custom lower limit of record_size_limit Martin Thomson
- Re: [TLS] custom lower limit of record_size_limit Nikos Mavrogiannopoulos
- Re: [TLS] custom lower limit of record_size_limit Martin Thomson