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$