Re: [TLS] [Technical Errata Reported] RFC8446 (5874)

Andrei Popov <Andrei.Popov@microsoft.com> Fri, 25 October 2019 18:13 UTC

Return-Path: <Andrei.Popov@microsoft.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 DCB7E1200DF for <tls@ietfa.amsl.com>; Fri, 25 Oct 2019 11:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 kjIDwUhkf8Rk for <tls@ietfa.amsl.com>; Fri, 25 Oct 2019 11:13:20 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740130.outbound.protection.outlook.com [40.107.74.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037CB120043 for <tls@ietf.org>; Fri, 25 Oct 2019 11:13:19 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TZDq3sajkPvsy1gHpRkiUnOk8CVaHC/FY3AehiC6ANjEvU9FyWoumt4ribJUFAndjEZgm5s3VcO7+i4a1rbHzt1BOE6k84u1votE95vYWjhnlvqcfSIsYV0qa5OJz8zK0qU/twAhe2Ms9+ZVH1DoUkrT9PeOTZK1NaV0GLX1euD0FG6E2n57ijreEvPK2yN3EV8CfFmcvpwCOTVs/6LXvlYaBtWLX86RXcY/+GTyMTBW+epXoM5ZIF6uU1XYW28he6EVevrsGGspna7NzqU2Q0pzLHmXwssFrXInE6aCZIvOJCcqRmRkBPY5QyWQ77Te/1Vn3vtpgeVzDeVOstgHPg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/KiHVAXi5Fe20W0kW+DmklPj/NC6+kZyYS89O0XE4wY=; b=abJWA+NYwr2TaezZPVeHuo3xK1lpLOcDjtOrR0jlnkpJ78IJKTntxI7rhYdw7tUJmfT9396iUnWU/S7kZu41o/bH49vfYoKznBhZXdCnTt/buykinou0qAizqd/6DV9UnOaQBxPeTmkUOCf2bex3BTlGGg7/T60H9tYsmRHMg9RL88gaNqn8xeF4ye7NKlFb0wm4cs9ycyW2kVf2/eI0vXKXeBxeGC4tSJGIJiromX/9aQabMpBz0NgzoO4sFGGhuVAMSKnB5oJGc1wzc41koIO3IuuZWeIedBm+FCDMU71PFquz/KZ54tyqGEjfTigXbvnvALqn9qMvMY0VFKBvJQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/KiHVAXi5Fe20W0kW+DmklPj/NC6+kZyYS89O0XE4wY=; b=drhxr+NBt2Ib7FY2y8kIZmuvFfvemNV9FTyxnuhnC7PtBQdLgnIl07VB0Lk4Hf0rdGefZ5+DNdAcuQgg5akgY6VxeizH81Q481xdaXW3W7EFyyuEOufDU7q3B9Tz3XFBYHZfEUDtnyh7TYrhvLHdDIUWn6KSk8XT2a/CxIEME5Q=
Received: from DM5PR2101MB0997.namprd21.prod.outlook.com (52.132.133.31) by DM5PR2101MB1047.namprd21.prod.outlook.com (52.132.128.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.9; Fri, 25 Oct 2019 18:13:18 +0000
Received: from DM5PR2101MB0997.namprd21.prod.outlook.com ([fe80::602d:42fc:b602:ecd4]) by DM5PR2101MB0997.namprd21.prod.outlook.com ([fe80::602d:42fc:b602:ecd4%7]) with mapi id 15.20.2387.014; Fri, 25 Oct 2019 18:13:18 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, "ekr@rtfm.com" <ekr@rtfm.com>, "rdd@cert.org" <rdd@cert.org>, "kaduk@mit.edu" <kaduk@mit.edu>, "caw@heapingbits.net" <caw@heapingbits.net>, "joe@salowey.net" <joe@salowey.net>, "sean+ietf@sn3rd.com" <sean+ietf@sn3rd.com>
CC: "lperrin@bellaliant.net" <lperrin@bellaliant.net>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] [Technical Errata Reported] RFC8446 (5874)
Thread-Index: AQHVgLSpd7FDKHjDJUC+OKeaNh4g+qdrvRNQ
Date: Fri, 25 Oct 2019 18:13:18 +0000
Message-ID: <DM5PR2101MB09977EBA4B790C4711E7059A8C650@DM5PR2101MB0997.namprd21.prod.outlook.com>
References: <20191012042149.A9B79B801A8@rfc-editor.org>
In-Reply-To: <20191012042149.A9B79B801A8@rfc-editor.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-originating-ip: [2001:4898:80e8:1:18b2:a023:971b:e42c]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: badebe31-751c-4792-079f-08d759770312
x-ms-traffictypediagnostic: DM5PR2101MB1047:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <DM5PR2101MB1047AD0FAE058E4B0697C61C8C650@DM5PR2101MB1047.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02015246A9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(396003)(376002)(346002)(39860400002)(366004)(199004)(13464003)(189003)(54906003)(256004)(99286004)(46003)(9686003)(478600001)(6306002)(966005)(55016002)(10090500001)(186003)(86362001)(10290500003)(7696005)(6506007)(11346002)(22452003)(2501003)(316002)(486006)(6436002)(446003)(74316002)(71190400001)(4326008)(33656002)(14454004)(110136005)(71200400001)(7736002)(2171002)(102836004)(8990500004)(14444005)(53546011)(76176011)(6246003)(8676002)(229853002)(2906002)(305945005)(81156014)(52536014)(6116002)(76116006)(2201001)(8936002)(5660300002)(64756008)(66446008)(66946007)(66476007)(66556008)(476003)(81166006)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1047; H:DM5PR2101MB0997.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: METPu1vKkkIkYOph9527PCWIuakf7ptofya+p11rlNNjbZTlQVKf3f138vH/KRfRr3dMzFMqm5X4mE1mlKkMccrcETIqLgV3JX6P1y0F0cSVs1eFt/IbGv9ZcE7p9UGn00wlph8BQuvXriwmqy+45kMTXdkC7/dULkV25lRq1sFBTha0ATjP7LnB0HjtzRZMLvR+k9Adk49eG+beuQzcpIuWdskKOJQ4YRDHeB7zH8khFEvM28+22iVcC3eBMk54cWoz/HZOF2CtOdSmiJaGwMB/eWMyenBzYGwEV2pmZ++bg++LRkfC/6D5mO13iKkPWgQXfmA4ok331SiVts70JTVYHVECMPUqy3FzCe3mxDXi3kmL3k5uf5w1epEJdEzZsxdQI3gu+FFh63Gd1mVPNBcGnme45uTKyQ8proESLixaMtDv7HOaqtVUW97Xu1XbHCz0CIJhSyTBi3hPe7sOlV1QDKYYU1Tkfk+6ifuHv3I=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: badebe31-751c-4792-079f-08d759770312
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2019 18:13:18.2558 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TKZw0qlBiXCKSe/cjYyr+6R3+mjU7oV1GglN9ZUaMwHveJ3wmw1Bc2qqMrcR0APXyHgV+LDxvxm1RmxX8bn21Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1047
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qNSbWVPIoiw2Yix8kIz-VvC2yVk>
Subject: Re: [TLS] [Technical Errata Reported] RFC8446 (5874)
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: Fri, 25 Oct 2019 18:13:23 -0000

My reading of the TLS 1.2 and 1.3 RFCs is that zero-length application_data records must still be encrypted and authenticated. Otherwise, MITM can inject arbitrary numbers of these.

However, the current language is vague enough that I've seen major SW vendors send (and accept) 0x17 0x03 0x03 0x00 0x00 and insist that this is RFC-compliant, because " Zero-length fragments of Application Data MAY be sent".

Therefore, I support clarifications in this area.

Cheers,

Andrei

-----Original Message-----
From: TLS <tls-bounces@ietf.org>; On Behalf Of RFC Errata System
Sent: Friday, October 11, 2019 9:22 PM
To: ekr@rtfm.com; rdd@cert.org; kaduk@mit.edu; caw@heapingbits.net; joe@salowey.net; sean+ietf@sn3rd.com
Cc: lperrin@bellaliant.net; tls@ietf.org; rfc-editor@rfc-editor.org
Subject: [TLS] [Technical Errata Reported] RFC8446 (5874)

The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3".

--------------------------------------
You may review the report below and at:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5874&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889&amp;sdata=61wnX96xJGd6FSLbxEQAJNvwERSVAMGoxxvjgb7DuRo%3D&amp;reserved=0

--------------------------------------
Type: Technical
Reported by: Mr Laurie Perrin <lperrin@bellaliant.net>;

Section: 5.1

Original Text
-------------
....

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data MAY be sent, as they are potentially
   useful as a traffic analysis countermeasure.  Application Data
   fragments MAY be split across multiple records or coalesced into a
   single record.

Corrected Text
--------------
....

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data (i.e. those encapsulating an
   TLSInnerPlaintext record having a content field of length zero)
   MAY be sent, as they are potentially useful as a traffic analysis
   countermeasure. Application Data fragments MAY be split across
   multiple records or coalesced into a single record.

Notes
-----
In the interest of clarity, it may be prudent to specify the type of record for which a fragment of length zero is being considered - it cannot be that of the TLSCiphertext itself, for "Application Data messages are always protected,"
therefore I infer this relates to the TLSInnerPlaintext content field (of length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment.

Note: This comment also applies to previous versions of the TLS specification, in particular with the introduction of the respective text concerning zero-length fragments in RFC 5246. In TLS 1.2, this would be the GenericXXCipher content field of length "TLSCompressed.length" - i.e. to the TLSCompressed fragment.

Note: The implications of zero-length records must be considered with respect to potential vectors for denial of service.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8446 (draft-ietf-tls-tls13-28)
--------------------------------------
Title               : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date    : August 2018
Author(s)           : E. Rescorla
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
TLS mailing list
TLS@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889&amp;sdata=khYsCm5Wgkg98VESyOV8pNZCqEhA7EWLQhGE6%2FtOgos%3D&amp;reserved=0