[TLS] [Technical Errata Reported] RFC6347 (4103)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 08 September 2014 18:41 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EAB1A02F2 for <tls@ietfa.amsl.com>; Mon, 8 Sep 2014 11:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.655
X-Spam-Level:
X-Spam-Status: No, score=-106.655 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 zH-zRkg4tTsw for <tls@ietfa.amsl.com>; Mon, 8 Sep 2014 11:41:06 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7436E1A02EE for <tls@ietf.org>; Mon, 8 Sep 2014 11:41:06 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 35089180015; Mon, 8 Sep 2014 11:40:58 -0700 (PDT)
To: ekr@rtfm.com, nagendra@cs.stanford.edu, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, jsalowey@cisco.com
X-PHP-Originating-Script: 6000:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20140908184058.35089180015@rfc-editor.org>
Date: Mon, 08 Sep 2014 11:40:58 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6PrAKG_QSF5nS3fY2_NIMTCe4PY
Cc: mpg@polarssl.org, tls@ietf.org, rfc-editor@rfc-editor.org
Subject: [TLS] [Technical Errata Reported] RFC6347 (4103)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 08 Sep 2014 18:41:08 -0000
The following errata report has been submitted for RFC6347, "Datagram Transport Layer Security Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=4103 -------------------------------------- Type: Technical Reported by: Manuel Pégourié-Gonnard <mpg@polarssl.org> Section: 4.2.1 Original Text ------------- [p. 15] DTLS 1.2 server implementations SHOULD use DTLS version 1.0 regardless of the version of TLS that is expected to be negotiated. [p. 16] The server MUST use the same version number in the HelloVerifyRequest that it would use when sending a ServerHello. [p. 15] DTLS 1.2 and 1.0 clients MUST use the version solely to indicate packet formatting (which is the same in both DTLS 1.2 and 1.0) and not as part of version negotiation. In particular, DTLS 1.2 clients MUST NOT assume that because the server uses version 1.0 in the HelloVerifyRequest that the server is not DTLS 1.2 or that it will eventually negotiate DTLS 1.0 rather than DTLS 1.2. [p. 16] Upon receipt of the ServerHello, the client MUST verify that the server version values match. Corrected Text -------------- [p. 15] DTLS 1.2 server implementations MAY use DTLS version 1.0 regardless of the version of TLS that is expected to be negotiated, or the version that is expected to be negotiated. [p. 15] DTLS 1.2 and 1.0 clients MUST use the version solely to indicate packet formatting (which is the same in both DTLS 1.2 and 1.0) and not as part of version negotiation. In particular, DTLS 1.2 clients MUST NOT assume that because the server uses version 1.0 in the HelloVerifyRequest that the server is not DTLS 1.2 or that it will eventually negotiate DTLS 1.0 rather than DTLS 1.2. [p. 16] [Delete text relating to HelloVerifyRequest.server_version] Notes ----- The statements on the bottom of page 15 and on the top of page 16 are mutually contradictory. It looks like the statements on page 16 were copied from RFC 4347, but the intention was to replace them with the version from page 15 in this revision of the standard. 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 (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6347 (draft-ietf-tls-rfc4347-bis-06) -------------------------------------- Title : Datagram Transport Layer Security Version 1.2 Publication Date : January 2012 Author(s) : E. Rescorla, N. Modadugu Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG
- [TLS] [Technical Errata Reported] RFC6347 (4103) RFC Errata System