Re: [TLS] [Technical Errata Reported] RFC5246 (5409)

Benjamin Kaduk <kaduk@mit.edu> Wed, 27 June 2018 03:30 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 A9D98130F24 for <tls@ietfa.amsl.com>; Tue, 26 Jun 2018 20:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 LZ-F2kJZxbz1 for <tls@ietfa.amsl.com>; Tue, 26 Jun 2018 20:30:28 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 8DA92130E7A for <tls@ietf.org>; Tue, 26 Jun 2018 20:30:28 -0700 (PDT)
X-AuditID: 1209190c-219ff70000003fb4-34-5b3304d3828c
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 20.B4.16308.3D4033B5; Tue, 26 Jun 2018 23:30:27 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w5R3UP1c017900; Tue, 26 Jun 2018 23:30:26 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5R3UKJo022366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jun 2018 23:30:22 -0400
Date: Tue, 26 Jun 2018 22:30:20 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: =?iso-8859-1?Q?Eug=E8ne?= Adell <eugene.adell@gmail.com>
Cc: Sean Turner <sean@sn3rd.com>, Tim Dierks <tim@dierks.org>, Eric Rescorla <ekr@rtfm.com>, Joe Salowey <joe@salowey.net>, TLS WG <tls@ietf.org>
Message-ID: <20180627033020.GT79565@kduck.kaduk.org>
References: <20180626122858.D3574B80C41@rfc-editor.org> <45C8098C-A6D3-4E7B-BC3C-858C069D8B1D@sn3rd.com> <CALY=zUd0VSQZh=UdQMaB0ekj+RX9Bn0X7BZiuZmrhTZAS9CGsg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALY=zUd0VSQZh=UdQMaB0ekj+RX9Bn0X7BZiuZmrhTZAS9CGsg@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBKsWRmVeSWpSXmKPExsUixG6nrnuZxTjaYPZRYYsVr8+xW9w885fV Ytum/ewWV1Y1Mlv83jOP3eLT+S5GBzaPX2sWs3nsnHWX3WPJkp9MHpMftzF7HN+1gd3j4EHG ALYoLpuU1JzMstQifbsEroydO/cwFjxQrji07gpzA+Nu6S5GTg4JAROJ25+msXUxcnEICSxm kpiy6SwzhLORUeL3zt1QzlUmiWNLFjGDtLAIqEqsXLGREcRmE1CRaOi+DBYXEbCRePJ3M1gD s8BiRoljr/YzgSSEBcwlTm48DNbAC7Tv3865rHArTq2byAaREJQ4OfMJC4jNLKAu8WfeJaBJ HEC2tMTyfxwQYXmJ5q2zwZZxCgRK/N85BcwWFVCW2Nt3iH0Co+AsJJNmIZk0C2HSLCSTFjCy rGKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11MvNLNFLTSndxAiKFE5Jnh2MZ954HWIU4GBU4uE1 cDKKFmJNLCuuzD3EKMnBpCTKu7IcKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE99hbw2gh3pTE yqrUonyYlDQHi5I4b/YixmghgfTEktTs1NSC1CKYrAwHh5IErywwIQgJFqWmp1akZeaUIKSZ ODhBhvMADWdnAqrhLS5IzC3OTIfIn2LU5fjzfuokZiGWvPy8VClx3o3MQEUCIEUZpXlwc0AJ TiJ7f80rRnGgt4R5d4FU8QCTI9ykV0BLmICWuLYbgSwpSURISTUwBr8SXeouNvdE/u1mg533 dnAdtdh4TOre3ohTnYnPDaawtivcPbP7pb+R0kWp1Vc/TlfxNOT8qrryWHfwq4+n9haxSr4O ejp749nblcXdN+d+8FxWeu1GRPqSXx+j6k84Ffb9cFH/eEjGdN5LnxMdj1X/nDhZf1yKVVDR v4Cn8MeUkKMC5mqnpiixFGckGmoxFxUnAgBLhcy5SwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/I9Y4dUurrSQyFwppqdEo2QssP6Y>
Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (5409)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 27 Jun 2018 03:30:31 -0000

I don't really think this is a useful erratum against 5246; the note there
is providing an explanation for why certain values are not used (and should
not be used).  But, now, and even at the time 5246 was published, 0x001e
*is* used, and there's no reason to mention it in this context.  One could
perhaps argue that 2712 should have noted that a value was being reused (or
have not reused the value at all), and an errata report against 2712 to add
a new appendix section might be reasonable.

So, absent additional considerations, I plan to reject this report.

-Ben

On Tue, Jun 26, 2018 at 04:01:35PM +0200, Eugène Adell wrote:
> Hello,
> 
> I had some doubts whether it was technical or editorial, and I have looked
> at some accepted errata to choose (maybe not the best method) . I thought
> it was technical, because one cipher suite was replaced by another one, and
> the note already existing gives their numbers, which is a technical
> information.
> 
> Although the "mistake" first appears in RFC2712 draft 01, RFC2246 final
> release was published before the final RFC2712.
> RFC2246 is obsoleted but mentions Fortezza, which RFC2712 doesn't. RFC5246
> being the only non obsoleted child of RFC2246 mentionning the Fortezza
> group, it looked more natural to suggest the errata at this place instead
> of RFC2712 which is fully dedicated to Kerberos.
> 
> 
> best regards
> Eugène
> 
> 
> 
> Le mar. 26 juin 2018 à 15:21, Sean Turner <sean@sn3rd.com>; a écrit :
> 
> > First, I think this is editorial.  After all these years, I’m not really
> > sure it’s an interop problem.
> >
> > Second, if I were making this I would have placed the errata against
> > RFC2712 where the values were assigned.  It’s not really TLS1.2’s place to
> > clear this up.
> >
> > spt
> >
> > > On Jun 26, 2018, at 08:28, RFC Errata System <rfc-editor@rfc-editor.org>;
> > wrote:
> > >
> > > The following errata report has been submitted for RFC5246,
> > > "The Transport Layer Security (TLS) Protocol Version 1.2".
> > >
> > > --------------------------------------
> > > You may review the report below and at:
> > > http://www.rfc-editor.org/errata/eid5409
> > >
> > > --------------------------------------
> > > Type: Technical
> > > Reported by: Eugene Adell <eugene.adell@gmail.com>;
> > >
> > > Section: Appendix A.5
> > >
> > > Original Text
> > > -------------
> > >   Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
> > >   reserved to avoid collision with Fortezza-based cipher suites in
> > >   SSL 3.
> > >
> > > Corrected Text
> > > --------------
> > >   Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
> > >   reserved to avoid collision with Fortezza-based cipher suites in
> > >   SSL 3. The cipher suite value { 0x00, 0x1E } firstly also assigned to
> > >   Fortezza has been released and has since been be reassigned.
> > >
> > > Notes
> > > -----
> > > RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer
> > Security) in its Draft 01 version introduces three new cipher suites
> > colliding with the three Fortezza ones. The Draft 02 version partially
> > corrects that, by moving the Kerberos cipher suites values by two.
> > > This omission of the third cipher suite has never been corrected, and
> > this remains in the same state in the final RFC 2712, RFC 2246 and its
> > successors including this one.
> > >
> > > Changing the first Kerberos cipher suite value, or moving all of them,
> > would now not make any sense. Enhancing the note as suggested is probably
> > enough to mention how one Fortezza cipher suite disappeared.
> > >
> > > 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.
> > >
> > > --------------------------------------
> > > RFC5246 (draft-ietf-tls-rfc4346-bis-10)
> > > --------------------------------------
> > > Title               : The Transport Layer Security (TLS) Protocol
> > Version 1.2
> > > Publication Date    : August 2008
> > > Author(s)           : T. Dierks, E. Rescorla
> > > Category            : PROPOSED STANDARD
> > > Source              : Transport Layer Security
> > > Area                : Security
> > > Stream              : IETF
> > > Verifying Party     : IESG
> >
> >