Subject: Re: [TLS] TLS grammar checker?

From: Peter Gutmann <[email-masked]>
Date: Mon, 17 Jun 2013 06:09:04 +0000

Paul Hoffman <[email-masked]> writes:

>Greetings again. The recent errata shows that some of the TLS documents that
>use the grammar invented for SSL can have some errors. People have developed
>tools for checking ABNF grammar in Internet Drafts and RFCs; has anyone
>developed an SSL grammar checker?

The SSL grammar isn't, AFAIK, any kind of machine-parseable formal grammar, in
published automated analyses the authors had to re-state what was going on in
their own notation in order to make it amenable to automated analysis, and
even then could usually only do a subset of the protocol.  So you'd need to
come up with your own grammar that's amenable to automated processing and re-
specific TLS in that.  I can't really see that happening any time soon.

(Having said that, I'd like to see it done.  The grammar used in the SSL/TLS
RFCs is pretty confusing in places).

Peter.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Jun 2013 06:48:44 -0700

> specific TLS in that.  I can't really see that happening any time soon.

Indeed, so my question was hopeful that it had been done in the past. 

> RFCs is pretty confusing in places).

It could be / would have been an interesting task for a CS intern or summer student, or a prof researching widely-used grammars.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Jun 2013 06:59:41 -0700

On Mon, Jun 17, 2013 at 6:48 AM, Paul Hoffman <[email-masked]> wrote:

> It could be / would have been an interesting task for a CS intern or
> summer student, or a prof researching widely-used grammars.
>

I've built parsers for subsets of the grammar. I'm not sure anyone has
built one for the entire TLS protocol. I think you would probably have to
iterate:

1. Build the parser.
2. Try to parse the grammar in the specifications.
3. Look at where it fails and try to decide whether your parser
    was wrong or the specs were wrong.
4. File errata and/or fix your parser.
5. Rinse, repeat

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 Jun 2013 12:55:31 -0400

> (Having said that, I'd like to see it done.  The grammar used in the 
> SSL/TLS RFCs is pretty confusing in places).

Any support for using a standard like, say, ASN.1 ?

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 18 Jun 2013 10:09:38 -0700

> Any support for using a standard like, say, ASN.1 ?

No.

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Jun 2013 12:36:34 -0500

> Any support for using a standard like, say, ASN.1 ?

If you want to use something like XDR or ASN.1 you'll need to provide
some open source tooling so that at least content of new TLS-related
I-Ds/RFCs can be syntax-validated.  Otherwise you'll probably get no
consensus.  Not that such tooling would be sufficient for consensus
either (but I'd support it).

Nico

PS: I've thought of defining my own ad-hoc ASN.1 encoding rules for
various purposes.  I'd like a JSON encoding rules for pretty-printing
things that will be encoded in or have been decoded from
BER/DER/PER/...  This would make it possible to use ASN.1 for
specifying JSON schemas too, but no one who doesn't already have to
use ASN.1 wants to use ASN.1, though I myself like ASN.1 -- I only
hate its TLV encodings.

---

From: Bill Frantz <[email-masked]>
Date: Tue, 18 Jun 2013 15:20:07 -0700

On 6/18/13 at 10:36 AM, [email-masked] (Nico Williams) wrote:

>This would make it possible to use ASN.1 for

Given the history of serious security problems due to ASN.1 
parser bugs, I would feel better with a simpler format. (And 
yes, I'm one of the people who developed an allergy to ASN.1 
through use.)

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        |The nice thing about standards| Periwinkle
(408)356-8506      |is there are so many to choose| 16345 
Englewood Ave
www.pwpconsult.com |from.   - Andrew Tanenbaum    | Los Gatos, 
CA 95032

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Jun 2013 17:49:59 -0500

On Tue, Jun 18, 2013 at 5:20 PM, Bill Frantz <[email-masked]> wrote:
> Given the history of serious security problems due to ASN.1 parser bugs, I
> would feel better with a simpler format. (And yes, I'm one of the people who
> developed an allergy to ASN.1 through use.)

This tells me that you don't understand what you're talking about,
that your reaction is knee-jerk.

ASN.1 is just a syntax.  The security bugs have been in decoders of
some encoding rules of ASN.1, like BER.

And there have been security vulnerabilities in *many* encodings not
related to ASN.1, such as XDR, NDR, and others.  The problem is not
exclusive to TLV (tag-length-value) encoding rules of ASN.1 (like BER)
nor to ASN.1 encoding rules.  It's generic.

The syntax itself is fine as far as security goes.  It's not terribly
easy to parse (so that's one reason not to use it), that's about the
only significant problem with the *syntax*.

I'd go further and recommend the use of a syntax and encoding rules
for which there is suitable tooling available as this allows for more
formality in specifications, and fixing of bugs by fixing
encoder/decoder libraries, increasing code reuse, ...

Nico
--

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 18 Jun 2013 19:26:58 -0400

Having written my share of ASN.1 stuff (including parser/encoder with no known vulnerabilities :), I agree with Nico's assessment of ASN.1.

TNX!
--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <[email-masked]>
Lexington, MA  02420-9185       

Web:  http://www.ll.mit.edu/CST/

MIT LL Root CA: 

 <https://www.ll.mit.edu/labcertificateauthority.html>

DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Nico Williams [mailto:[email-masked]]
Sent: Tuesday, June 18, 2013 05:49 PM
To: Bill Frantz <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [TLS] TLS grammar checker?

Nico
--
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 19 Jun 2013 07:49:36 -0400

To quell some other commentary, I wasn't talking about creating any kind of automatic code generation. Yesterday afternoon I wrote a yacc/lex (er, Bison/flex) parser that seems to get the syntax right. It doesn't do any semantic checking (e.g., duplicate choices in an enumeration). Not sure if I'll go any further with it, so if you want it drop me a line.

I think there is a great benefit to using a standard language. The knee-jerk "no" to my ASN.1 suggestion doesn't surprise me. XSD is another possibility, but that seems too ... weird .. for me. Many other IETF security standards use ASN1, the documentation is freely available, it is widely known and understood, and some tools are available. If I get some free time later in the summer I might experiment with it.

	/r$

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Jun 2013 07:11:57 -0700

> To quell some other commentary, I wasn't talking about creating any kind of automatic code generation. Yesterday afternoon I wrote a yacc/lex (er, Bison/flex) parser that seems to get the syntax ri…

Please do let the list know where the tool can be found. It would be useful to check current and future extension documents, and the future 1.3 document.

--Paul Hoffman

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 20 Jun 2013 12:08:51 -0400

> To quell some other commentary, I wasn't talking about creating any kind of automatic code generation. Yesterday afternoon I wrote a yacc/lex (er, Bison/flex) parser that seems to get the syntax ri…

In case anyone's interested: https://docs.google.com/file/d/0B8YgrWYHqacSNDhCekgtWUVPMW8/edit?usp=sharing It's 210 lines of code in the public domain.  Hope it's useful.

> I think there is a great benefit to using a standard language. The knee-jerk "no" to my ASN.1 suggestion doesn't surprise me. XSD is another possibility, but that seems too ... weird .. for me. Man…

Still true :)

	/r$

---

From: [email-masked] (Martin Rex)
Date: Fri, 21 Jun 2013 01:49:47 +0200 (CEST)

Salz, Rich wrote:
> 
> Many other IETF security standards use ASN1, the documentation is
> freely available, it is widely known and understood, and some tools
> are available.

ASN.1 ... is ... widely ... known ... and ... understood ?

I haven't met anyone who understands ASN.1 so far (which is different
from folks who believe they do or folks who use it to write poor specs).

-Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 21 Jun 2013 06:28:57 -0400

> ASN.1 ... is ... widely ... known ... and ... understood ?

Compared to the alternatives, yes.  Look at what data  definition languages are used in RFC's. 

	/r$

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Fri, 21 Jun 2013 07:21:30 -0400

Couldn't have said it better myself. :-)

MIT LL Root CA: 

----- Original Message -----
From: Salz, Rich [mailto:[email-masked]]
Sent: Friday, June 21, 2013 05:28 AM
To: [email-masked] <[email-masked]>
Cc: [email-masked] ([email-masked]) <[email-masked]>
Subject: Re: [TLS] TLS grammar checker?

	/r$

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 21 Jun 2013 15:17:09 +0200

> Compared to the alternatives, yes.  Look at what data  definition languages are used in RFC's.

Actually ASN.1 is the minority in definition languages in RFCs and I
believe much more people understand HTTP or SMTP than ASN.1.

There was a reason ASN.1 was avoided in the TLS protocol, and that is
simplicity(*). I don't think much has changed since then.

regards,
Nikos

(*). See for example the note on the usage of PKCS #6 in RFC2246.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 21 Jun 2013 09:23:16 -0400

> Actually ASN.1 is the minority in definition languages in RFCs and I believe much more people understand HTTP or SMTP than ASN.1.

Perhaps I wasn't clear by data definition language.  I mean things like XSD, SQL schema, OMG IDL, RPC NDR, etc.

Yes, of course many more folks understand HTTP and SMTP.  But compare like to like.

What other data definition language are there besides SSL/TLS, ABNF, and ASN.1?

	/r$

---

From: [email-masked] (Martin Rex)
Date: Fri, 21 Jun 2013 21:21:55 +0200 (CEST)

Salz, Rich wrote:
> Compared to the alternatives, yes.
> Look at what data  definition languages are used in RFC's. 

To illustrate one of my many problems with ASN.1 complexity and lack
of clarity, I was recently wondering on OCSP, whether it is permissible
or not _on_receipt_ when the "RevodedInfo->revocationTime" element

   http://tools.ietf.org/html/rfc2560#page-9

or the CRL Extension "CRL References" "CrlID->crlTime" element

   http://tools.ietf.org/html/rfc2560#section-4.4.2

contains a date&time with only 2-year, where exactly in ASN.1 it
is described how the receiver ought to be implemented, and whether
support for 2-digit years in GeneralizedTime is a "MAY", "SHOULD NOT"
or "MUST NOT".

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 21 Jun 2013 20:42:45 +0000

Of all the possible criticisms of ASN.1, this doesn't seem to be among them.  X.680 is unambiguous - the year MUST be 4 digits:

  46.3 The type is defined, using ASN.1, as follows:
      GeneralizedTime ::= [UNIVERSAL 24] IMPLICIT VisibleString
      with the values of the VisibleString restricted to strings
      of characters which are either:
          a) a specification of a calendar date followed by a local
             time, consisting of:
             1) a string representing the calendar date, as specified
                in ISO 8601, 4.1.2.2 - Basic format); followed by:

                 NOTE 1 - This specifies a four-digit representation
                 of the year, a two-digit representation of the month
                 and a two-digit representation of the day, without
                 use of separators.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Friday, June 21, 2013 3:22 PM
To: Salz, Rich
Cc: [email-masked] ([email-masked])
Subject: Re: [TLS] TLS grammar checker?

> Look at what data  definition languages are used in RFC's. 

To illustrate one of my many problems with ASN.1 complexity and lack of clarity, I was recently wondering on OCSP, whether it is permissible or not _on_receipt_ when the "RevodedInfo->revocationTime" element

contains a date&time with only 2-year, where exactly in ASN.1 it is described how the receiver ought to be implemented, and whether support for 2-digit years in GeneralizedTime is a "MAY", "SHOULD NOT"
or "MUST NOT".

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 21 Jun 2013 22:58:37 +0200 (CEST)

Kemp, David P. wrote:
> Of all the possible criticisms of ASN.1, this doesn't seem to be
> among them.  X.680 is unambiguous - the year MUST be 4 digits:

Your answer is way off the target.

I didn't ask about what to send out, but what to accept(!) and why.

rfc2560 OSCP is based on X.690-1994:
   http://tools.ietf.org/html/rfc2560#section-6

   [X.690]   ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995,
             Information Technology - ASN.1 encoding rules:
             Specification of Basic Encoding Rules (BER), Canonical
             Encoding Rules (CER) and Distinguished Encoding Rules
             (DER).

If you search X.680 from 1994 for GeneralizedTime, it only says that it
is a reserved keyword (therefore useless for the question at hand).

In order to figure out what to **ACCEPT**, you have to refer to the
original specifcation exclusively.

Your quote seems to be from X.680 2008.

-Martin

> contains a date&time with only 2-year, where exactly in ASN.1 it is
> described how the receiver ought to be implemented, and whether

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Jun 2013 16:06:44 -0500

>> among them.  X.680 is unambiguous - the year MUST be 4 digits:

Indeed.  And x.690 repeats this.

Nico
--

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 21 Jun 2013 21:28:28 +0000

My bad for not noticing that a 1999 standard (RFC 2560) referenced the 1994 specification of X.690.  However, the fact that the 1994 specification of ASN.1 is flawed is not a valid criticism of ASN.1 itself.  I'm sure HTML 4.01 (Dec 1999) fixed some errors and omissions in previous versions, and any deficiencies of RFC 1866 (HTML 2.0, Nov 1995) would not generally be considered valid flaws of HTML itself.

As for making a distinction between senders and receivers, "be liberal in what you accept" is no different for ASN.1 than for ABNF or bits-in-boxes - if your application wants to accept input that is syntactically invalid, it is free to do so.  The standard for syntax is the same for senders and receivers.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, June 21, 2013 4:59 PM
To: Kemp, David P.
Cc: [email-masked] ([email-masked])
Subject: Re: [TLS] TLS grammar checker?

Kemp, David P. wrote:
> Of all the possible criticisms of ASN.1, this doesn't seem to be among 
> them.  X.680 is unambiguous - the year MUST be 4 digits:

If you search X.680 from 1994 for GeneralizedTime, it only says that it is a reserved keyword (therefore useless for the question at hand).

In order to figure out what to **ACCEPT**, you have to refer to the original specifcation exclusively.

-Martin

> of clarity, I was recently wondering on OCSP, whether it is 
> permissible or not _on_receipt_ when the "RevodedInfo->revocationTime" 
> element
>

---

From: [email-masked] (Martin Rex)
Date: Fri, 21 Jun 2013 23:33:57 +0200 (CEST)

the most appropriate guidance is probably in X.208-1988 Section 32,
but the source of the original confusion is from where the information
originally comes from, that OCSP conveys in these fields.

When the mentioned OCSP elements originate from X.509 and PKIX CRLs,
then from an element that is defined as (e.g. rfc5280 page 17):

   Time ::= CHOICE {
        utcTime        UTCTime,
        generalTime    GeneralizedTime }

and the CRL definition (rfc5280, page 56):

   CertificateList  ::=  SEQUENCE  {
        tbsCertList          TBSCertList,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

   TBSCertList  ::=  SEQUENCE  {
        version                 Version OPTIONAL,
                                     -- if present, MUST be v2
        signature               AlgorithmIdentifier,
        issuer                  Name,
        thisUpdate              Time,
        nextUpdate              Time OPTIONAL,
        revokedCertificates     SEQUENCE OF SEQUENCE  {
             userCertificate         CertificateSerialNumber,
             revocationDate          Time,
             crlEntryExtensions      Extensions OPTIONAL
                                      -- if present, version MUST be v2
                                  }  OPTIONAL,
        crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
                                      -- if present, version MUST be v2
                                  }

But the real problem really isn't about whether you can find something
intelligible hidden somewhere in some X.something document, but how
clear will this be to an average implementor.  And on this particular
account, ASN.1 is a real nightmare.

-Martin

---

From: Carl Wallace <[email-masked]>
Date: Fri, 21 Jun 2013 17:38:03 -0400

See RFC5911 and RFC5912.  Those provide a nice collection.