[TLS] Errors in RFC5246

["Salz, Rich" <[e-mail]>]

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