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

Benjamin Kaduk <kaduk@mit.edu> Sat, 26 October 2019 05:53 UTC

Return-Path: <kaduk@mit.edu>
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 983F9120073 for <tls@ietfa.amsl.com>; Fri, 25 Oct 2019 22:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 JpHJ8KMXugdf for <tls@ietfa.amsl.com>; Fri, 25 Oct 2019 22:52:59 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 51EF4120071 for <tls@ietf.org>; Fri, 25 Oct 2019 22:52:59 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9Q5qm9e018622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 26 Oct 2019 01:52:50 -0400
Date: Fri, 25 Oct 2019 22:52:47 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, "ekr@rtfm.com" <ekr@rtfm.com>, "rdd@cert.org" <rdd@cert.org>, "caw@heapingbits.net" <caw@heapingbits.net>, "joe@salowey.net" <joe@salowey.net>, "sean+ietf@sn3rd.com" <sean+ietf@sn3rd.com>, "lperrin@bellaliant.net" <lperrin@bellaliant.net>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20191026055247.GT69013@kduck.mit.edu>
References: <20191012042149.A9B79B801A8@rfc-editor.org> <DM5PR2101MB09977EBA4B790C4711E7059A8C650@DM5PR2101MB0997.namprd21.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DM5PR2101MB09977EBA4B790C4711E7059A8C650@DM5PR2101MB0997.namprd21.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IFGyrWXa8zFUY9wcSn_eUjFt680>
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: Sat, 26 Oct 2019 05:53:02 -0000

Thanks for letting us know, Andrei.
That's rather depressing, but is fairly indicative that the errata report
should be verified.  (I think I will edit the "Notes" slightly when doing
so, but am too tired to do a proper job tonight, so I'm holding off on
actually marking the report as verified in the database for now.)

-Ben

On Fri, Oct 25, 2019 at 06:13:18PM +0000, Andrei Popov wrote:
> 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