[TLS] [Editorial Errata Reported] RFC5246 (2165)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 19 April 2010 21:47 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C52F3A69A8 for <tls@core3.amsl.com>; Mon, 19 Apr 2010 14:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.376
X-Spam-Level:
X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Apc8z8EvEjPq for <tls@core3.amsl.com>; Mon, 19 Apr 2010 14:47:10 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 27CF83A6984 for <tls@ietf.org>; Mon, 19 Apr 2010 14:47:02 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 0219613000D; Mon, 19 Apr 2010 14:46:53 -0700 (PDT)
To: tim@dierks.org, ekr@rtfm.com, turners@ieca.com, tim.polk@nist.gov, ekr@networkresonance.com, jsalowey@cisco.com, ekr@rtfm.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20100419214654.0219613000D@rfc-editor.org>
Date: Mon, 19 Apr 2010 14:46:53 -0700
X-Mailman-Approved-At: Mon, 19 Apr 2010 15:13:16 -0700
Cc: nmalykh@protocols.ru, tls@ietf.org, rfc-editor@rfc-editor.org
Subject: [TLS] [Editorial Errata Reported] RFC5246 (2165)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 19 Apr 2010 21:47:11 -0000
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_search.php?rfc=5246&eid=2165 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh <nmalykh@protocols.ru> Section: 6.2.3.2 Original Text ------------- Example: If the block length is 8 bytes, the content length (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, then the length before padding is 82 bytes (this does not include the Dierks & Rescorla Standards Track [Page 23] RFC 5246 TLS August 2008 IV. Thus, the padding length modulo 8 must be equal to 6 in order to make the total length an even multiple of 8 bytes (the block length). The padding length can be 6, 14, 22, and so on, through 254. If the padding length were the minimum necessary, 6, the padding would be 6 bytes, each containing the value 6. Thus, the last 8 octets of the GenericBlockCipher before block encryption would be xx 06 06 06 06 06 06 06, where xx is the last octet of the MAC. Corrected Text -------------- Example: If the block length is 8 bytes, the content length (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, then the length before padding is 82 bytes (this does not include the Dierks & Rescorla Standards Track [Page 23] RFC 5246 TLS August 2008 IV). Thus, the padding length modulo 8 must be equal to 6 in order to make the total length an even multiple of 8 bytes (the block length). The padding length can be 6, 14, 22, and so on, through 254. If the padding length were the minimum necessary, 6, the padding would be 6 bytes, each containing the value 6. Thus, the last 8 octets of the GenericBlockCipher before block encryption would be xx 06 06 06 06 06 06 06, where xx is the last octet of the MAC. Notes ----- Instructions: ------------- This errata 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. -------------------------------------- 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
- [TLS] [Editorial Errata Reported] RFC5246 (2165) RFC Errata System
- Re: [TLS] [Editorial Errata Reported] RFC5246 (21… Tim Dierks
- Re: [TLS] [Editorial Errata Reported] RFC5246 (21… Daniel Kahn Gillmor
- Re: [TLS] [Editorial Errata Reported] RFC5246 (21… Michael D'Errico
- Re: [TLS] [Editorial Errata Reported] RFC5246 (21… Yoav Nir
- Re: [TLS] [Editorial Errata Reported] RFC5246 (21… Sean Turner