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 > > > >
- Re: [TLS] [Technical Errata Reported] RFC5246 (54… Benjamin Kaduk
- Re: [TLS] [Technical Errata Reported] RFC5246 (54… Sean Turner
- [TLS] [Technical Errata Reported] RFC5246 (5409) RFC Errata System
- Re: [TLS] [Technical Errata Reported] RFC5246 (54… Eugène Adell