Subject: Re: [TLS] Errors in RFC5246

From: "Salz, Rich" <[email-masked]>
Date: Wed, 10 Jul 2013 17:45:00 -0400

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: [email-masked] ([email-masked])
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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 10 Jul 2013 17:52:25 -0400

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.

-----Original Message-----
From: Salz, Rich [mailto:[email-masked]] 
Sent: Wednesday, July 10, 2013 5:45 PM
To: [email-masked] ([email-masked])
Subject: Re: [TLS] Errors in RFC5246

Thanks.

	/r$

-----Original Message-----
From: Salz, Rich 
Sent: Tuesday, July 09, 2013 2:01 PM
To: [email-masked] ([email-masked])
Subject: Errors in RFC5246

Thanks.

            /r$

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