Re: [TLS] Errors in RFC5246

"Salz, Rich" <rsalz@akamai.com> Wed, 10 July 2013 21:52 UTC

Return-Path: <rsalz@akamai.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 911DD11E8139 for <tls@ietfa.amsl.com>; Wed, 10 Jul 2013 14:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.411
X-Spam-Level:
X-Spam-Status: No, score=0.411 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, SARE_OBFU_PART_ICE=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o285jz6VLYH9 for <tls@ietfa.amsl.com>; Wed, 10 Jul 2013 14:52:31 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [96.6.114.97]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4A211E8132 for <tls@ietf.org>; Wed, 10 Jul 2013 14:52:29 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4C0FE1C4806 for <tls@ietf.org>; Wed, 10 Jul 2013 21:52:27 +0000 (GMT)
Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 410251C4803 for <tls@ietf.org>; Wed, 10 Jul 2013 21:52:27 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 4C9B547BD2 for <tls@ietf.org>; Wed, 10 Jul 2013 21:52:26 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.196]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 10 Jul 2013 17:52:25 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>, "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Date: Wed, 10 Jul 2013 17:52:25 -0400
Thread-Topic: Errors in RFC5246
Thread-Index: Ac58ygbd4z3/DkAJRL2bdr4aRZHHNwA68QhAAABpAxA=
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B4BFB358@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C711B4BFB353@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711B4BFB353@USMBX1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Errors in RFC5246
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 10 Jul 2013 21:52:35 -0000

And a (hopefully last) set of items.

CompressionMethod is defined in Section 6.1 and Section 7.4.1.2; presumably the second one should be removed.

It is also defined in Section A.4.1 and Section A.6; presumably the second one should be removed.


--  
Principal Security Engineer
Akamai Technology
Cambridge, MA



-----Original Message-----
From: Salz, Rich [mailto:rsalz@akamai.com] 
Sent: Wednesday, July 10, 2013 5:45 PM
To: TLS@ietf.org (tls@ietf.org)
Subject: Re: [TLS] Errors in RFC5246

In addition to the errors below, I found a few other questionable items.

Section 7.4.1.2, in ClientHello: where does extensions_present come from?

Section 7.4.1.3 in ServerHello: where does extensions_present come from?

Section 7.4.8, in CertificateVerify: where does handshake_messages_length come from?

Section A.4.1 in ClientHello and in ServerHello: same question about extensions_present

Section A.4.3 in CertificateVerify: same question about handshake_messages_length

Thanks.

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA



-----Original Message-----
From: Salz, Rich 
Sent: Tuesday, July 09, 2013 2:01 PM
To: TLS@ietf.org (tls@ietf.org)
Subject: Errors in RFC5246

I updated my parser for the "presentation language" in the SSL/TLS RFC's.  I used RFC5246.

Here is an updated version:
  tlsgrammar.tar - https://docs.google.com/file/d/0B8YgrWYHqacSNDhCekgtWUVPMW8/edit?usp=sharing

The presentation language definition in section four has a number of errors. Unfortunately, I only remember those that are related to the choices in a variant; they are documented in the README file.

As for  the examples in the RFC, looking at a diff between the original and changes I made, I have the following errors:

Section 4.7:  "digitally-signed opaque" should be "digitally-signed struct" And shouldn't that struct have a name?

Section 7.4.1.2 in ClientHello: should cipher_suites be <1..2^16-1>?  And "struct {};" for the false case isn't valid; I suggest using a single semicolon.

Section 7.4.1.3 in ServerHello; same comment about "struct {};" vs ";" for an empty variant.

Section 7.4.1.4.1 should supported_signature_algorithms be <1..2^16-1> ?

Section 7.4.2, "ASN.1Cert" is not a valid name since "." is the sub-field operator. I used "ASN1Cert"

Section 7.4.4, in CertificateRequest: see above question about supported_signature_algorithms

Section 7.4.7.2 in ClientDiffieHellmanPublic: I made dh_Yc a type and used it in the explicit case, since the current construct is not allowed by the presentation language.

Section 7.4.8 in CertificateVerify: The internal closing } is missing a semicolon. And shouldn't that struct have a name?

Section A.4 in HandshakeProtocol : missing a comma after the finished item.

Section A.4 in ClientHello: same comment about cipher_suites. Same note about the false case.

Section A.4 in ServerHello: same comment about the false case.

Section A.4.2: Same comment about ASN.1Cert changed to ASN1Cert

Section A.4.2 in ServerKeyExchange: the language requires that signed_params be pulled out into its on struct. When I do that, it becomes obvious that ServerDHParams is included twice, once plain and once part of the signed_params item. Is that correct?  Also, for the rsa/dh_dss/dh_rsa case, use a semicolon to indicate an empty choice.

Section A.4.3 same comment about ClientDiffieHellmanPublic

Thanks.

            /r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls