[TLS] editorial error in draft-ietf-tls-rfc4492bis-17
mrex@sap.com (Martin Rex) Tue, 24 October 2017 13:22 UTC
Return-Path: <mrex@sap.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 3931113F554 for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 06:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.021
X-Spam-Level:
X-Spam-Status: No, score=-5.021 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 dgUaStxT4tlf for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 06:22:21 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868B013F505 for <tls@ietf.org>; Tue, 24 Oct 2017 06:22:21 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3yLv7v3lMdz25TB for <tls@ietf.org>; Tue, 24 Oct 2017 15:22:19 +0200 (CEST)
X-purgate-ID: 152705::1508851339-000040CA-A4C958B1/0/0
X-purgate-size: 2433
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3yLv7v36jgzGph2 for <tls@ietf.org>; Tue, 24 Oct 2017 15:22:19 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6194A404B; Tue, 24 Oct 2017 15:22:19 +0200 (CEST)
To: tls@ietf.org
Date: Tue, 24 Oct 2017 15:22:19 +0200
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20171024132219.6194A404B@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EIwyBXjA2tkQWQlnE7FE9HVKz1I>
Subject: [TLS] editorial error in draft-ietf-tls-rfc4492bis-17
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 24 Oct 2017 13:22:28 -0000
I just noticed a strange inconsistency in section 6 of
draft-ietf-tls-rfc4492bis-17
https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-17#section-6
The last of the "must implement 1 of these 4" list of cipher suites at
the end of section 6 is not contained in the table at the beginning of
section 6 above it (instead, it appears in rfc5289 only).
I believe that the last ciphersuites should be changed (which will
provide consistence with the second list entry (the TLSv1.2 MTI cipher suite).
-Martin
+-----------------------------------------+----------------+
| CipherSuite | Identifier |
+-----------------------------------------+----------------+
| TLS_ECDHE_ECDSA_WITH_NULL_SHA | { 0xC0, 0x06 } |
| TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x08 } |
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x09 } |
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0A } |
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2B } |
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x2C } |
| | |
| TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } |
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } |
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } |
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } |
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2F } |
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x30 } |
| | |
| TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } |
| TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } |
| TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } |
| TLS_ECDH_anon_WITH_AES_256_CBC_SHA | { 0xC0, 0x19 } |
+-----------------------------------------+----------------+
Server implementations SHOULD support all of the following cipher
suites, and client implementations SHOULD support at least one of
them:
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+ o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256