Re: [TLS] FW: New Version Notification for draft-mattsson-tls-super-jumbo-record-limit-01.txt
Benjamin Kaduk <bkaduk@akamai.com> Fri, 01 March 2024 19:42 UTC
Return-Path: <bkaduk@akamai.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 EAF4BC14F61D; Fri, 1 Mar 2024 11:42:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9q9dD1ueaiR; Fri, 1 Mar 2024 11:42:12 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81EAC1516F8; Fri, 1 Mar 2024 11:42:12 -0800 (PST)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 421H4i4u008815; Fri, 1 Mar 2024 19:42:11 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; s= jan2016.eng; bh=zWbUNsN2WaUbOJIh1xKR/q9z2NHWPUzn4L2dqhfkMPI=; b= K6S+UxRd/5yr+0eAzZJ+MgKJXLh9skxo7RrDx27YOC5dClxi+C/17G9NXv6r1WUE 1BW31M8BwbHch7lMShirDQzRa0IXMsfKCjMo/xig70Ai7PCqAmONlMbswnMwc9c8 jyA/6lOvnMlc2H72nEtdhB8CC7JBmz1AS7TUw+BOcocpSxYrdTMHM5Av0yoiKXMI I7mDSvwwmqxV2gKvMiqVZwkxGKGt7uTMij0ovv4wUW6wpVu08/VTd+uChFqehQ0f +E1XqvWKt//MuTgy6E0cF8JiazsR73mfoDrcNm/ANAtRZguC8y2zJUtVfHqPZnSw ThwrTV6GMs9eIKeB40HKlg==
Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by mx0b-00190b01.pphosted.com (PPS) with ESMTPS id 3wkjyvbag4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Mar 2024 19:42:11 +0000 (GMT)
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.17.1.19/8.17.1.19) with ESMTP id 421GmIDu019829; Fri, 1 Mar 2024 14:42:10 -0500
Received: from email.msg.corp.akamai.com ([172.27.50.203]) by prod-mail-ppoint8.akamai.com (PPS) with ESMTPS id 3wfcp3b65g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Mar 2024 14:42:10 -0500
Received: from ustx2ex-dag4mb8.msg.corp.akamai.com (172.27.50.207) by ustx2ex-dag4mb4.msg.corp.akamai.com (172.27.50.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Fri, 1 Mar 2024 11:42:09 -0800
Received: from sea-lpsgbgy9.seattle.corp.akamai.com (172.27.164.43) by ustx2ex-dag4mb8.msg.corp.akamai.com (172.27.50.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28 via Frontend Transport; Fri, 1 Mar 2024 11:42:09 -0800
Date: Fri, 01 Mar 2024 11:42:07 -0800
From: Benjamin Kaduk <bkaduk@akamai.com>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
CC: "TLS@ietf.org" <tls@ietf.org>
Message-ID: <20240301194207.GL5993@sea-lpsgbgy9.seattle.corp.akamai.com>
References: <170893644436.41119.11924400263838671292@ietfa.amsl.com> <GVXPR07MB96788B85F9D903BEA03428C2895A2@GVXPR07MB9678.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <GVXPR07MB96788B85F9D903BEA03428C2895A2@GVXPR07MB9678.eurprd07.prod.outlook.com>
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-01_20,2024-03-01_03,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 adultscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2403010161
X-Proofpoint-GUID: 0jf6Z7vGCntdsh4LsanYr4KFPT6aZOwH
X-Proofpoint-ORIG-GUID: 0jf6Z7vGCntdsh4LsanYr4KFPT6aZOwH
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-01_20,2024-03-01_03,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 lowpriorityscore=0 phishscore=0 suspectscore=0 bulkscore=0 mlxlogscore=999 priorityscore=1501 clxscore=1011 mlxscore=0 malwarescore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2402120000 definitions=main-2403010163
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fzzeBLS3Cm9mnivAU2NOUP-juoU>
Subject: Re: [TLS] FW: New Version Notification for draft-mattsson-tls-super-jumbo-record-limit-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 01 Mar 2024 19:42:17 -0000
Hi John, I confess that my first impression was "eww, extensions with side effects on other extensions, that sounds super finicky to implement correctly". But actually reading in further, it seems more that the guiding principle is instead "only have one way to do a thing", in this case to communicate the maximum record size an endpoint is prepared to receive. That said, it's still changing the semantics of an existing field, which incurs a requirement to survey the compatibility with existing implementations. I see that RFC 8449 does carve out a way for endpoints to send larger values if "explicitly allowed by such a future version or extension. A server MUST NOT enforce this restriction" so in theory we should be okay, but we still need to actually check. I also note that the semantics of record_size_limit per RFC 8449 are to apply to the plaintext length, so I think it actually is weird and overly complicated for your draft to propose that the negotiated length will now be of the ciphertext length. -Ben On Mon, Feb 26, 2024 at 08:59:20AM +0000, John Mattsson wrote: > Hi, > > > > We just submitted version -01 of “Large Record Sizes for TLS and DTLS”. > Michael Tüxen is a new co-author, the extension has been renamed to the > more mundane “large_record_size" and is now a flag extension. The flag > extension is now used together with "record_size_limit" to allow > negotiation of maximum record size, not just a fixed 2^16 – 1 bytes. > > > > The use for record sizes larger than 2^14 has been discussed in TSVWG for > use in DTLS over SCTP and DTLS in SCTP. Large record sizes would be > beneficial in several of the discussed solutions to remove limitation or > to increase performance. > > > > We would like to present draft-mattsson-tls-super-jumbo-record-limit-01 in > Brisbane. > > > > Cheers, > > John Preuß Mattsson > > > > From: internet-drafts@ietf.org <internet-drafts@ietf.org> > Date: Monday, 26 February 2024 at 09:34 > To: John Mattsson <john.mattsson@ericsson.com>, Michael Tüxen > <tuexen@fh-muenster.de>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, > Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, John Mattsson > <john.mattsson@ericsson.com>, Michael Tuexen <tuexen@fh-muenster.de> > Subject: New Version Notification for > draft-mattsson-tls-super-jumbo-record-limit-01.txt > > A new version of Internet-Draft > draft-mattsson-tls-super-jumbo-record-limit-01.txt has been successfully > submitted by John Preuß Mattsson and posted to the > IETF repository. > > Name: draft-mattsson-tls-super-jumbo-record-limit > Revision: 01 > Title: Large Record Sizes for TLS and DTLS > Date: 2024-02-26 > Group: Individual Submission > Pages: 6 > URL: > [1]https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.txt > Status: > [2]https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/ > HTML: > [3]https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.html > HTMLized: > [4]https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit > Diff: > [5]https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-01 > > Abstract: > > RFC 8449 defines a record size limit extension for TLS and DTLS > allowing endpoints to negotiate a record size limit smaller than the > protocol-defined maximum record size, which is around 2^14 bytes. > This document specifies a TLS flag extension to be used in > combination with the record size limit extension allowing endpoints > to use a record size limit larger than the protocol-defined maximum > record size, but not more than about 2^16 bytes. > > The IETF Secretariat > > Links: > 1. https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.txt__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5PQtjvw8A$ > 2. https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5MOtgMACw$ > 3. https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.html__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5NSq7RMpA$ > 4. https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5O0NTWNIQ$ > 5. https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-01__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5Phx4rvmg$ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5O_FNpPMw$
- [TLS] FW: New Version Notification for draft-matt… John Mattsson
- Re: [TLS] FW: New Version Notification for draft-… Benjamin Kaduk
- Re: [TLS] FW: New Version Notification for draft-… John Mattsson