Subject: Re: [TLS] TLS grammar checker?

From: Bill Frantz <[email-masked]>
Date: Tue, 18 Jun 2013 17:05:33 -0700

I admire the optimism expressed here. Particularly given the 
state of computer security today.

[More inline]

Cheers - Bill

On 6/18/13 at 4:26 PM, [email-masked] (Blumenthal, Uri - 0558 - 
MITLL) wrote:

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

No known vulnerabilities is a good start. Unfortunately a lot of 
software is released with no know vulnerabilities but doesn't 
hold up under attack. It is nice to hear of software that has 
survived attack with no known vulnerabilities.

>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?
>
>On Tue, Jun 18, 2013 at 5:20 PM, Bill Frantz <[email-masked]> wrote:
>>On 6/18/13 at 10:36 AM, [email-masked] (Nico Williams) wrote:
>>
>>> 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.
>>
>>
>>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*.

Here is the reason I worry. The harder things are to do, the 
more likely mistakes will be made. That is why I prefer simpler formats.

While I'm bashing ASN.1, formats that allow infinite length data 
items are asking for buffer overruns.

>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
>--
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls
>
-----------------------------------------------------------------------
Bill Frantz        | I don't have high-speed      | Periwinkle
(408)356-8506      | internet. I have DSL.        | 16345 
Englewood Ave
www.pwpconsult.com |                              | Los Gatos, 
CA 95032

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Jun 2013 19:16:21 -0500

On Tue, Jun 18, 2013 at 7:05 PM, Bill Frantz <[email-masked]> wrote:
> On 6/18/13 at 4:26 PM, [email-masked] (Blumenthal, Uri - 0558 - MITLL)
> wrote:
>
>> Having written my share of ASN.1 stuff (including parser/encoder with no
>> known vulnerabilities :), I agree with Nico's assessment of ASN.1.
>
>
> No known vulnerabilities is a good start. Unfortunately a lot of software is
> released with no know vulnerabilities but doesn't hold up under attack. It
> is nice to hear of software that has survived attack with no known
> vulnerabilities.

Automatic tooling is a better start.  I.e., ASN.1, XDR, IDL, ... compilers.

Ad-hoc syntaxes don't lend themselves to automatic tooling, so they
tend to result in lots of error-prone hand-coding.

What are you arguing for?  (Mind you, this really isn't the right
place...  that goes for me too)

> Here is the reason I worry. The harder things are to do, the more likely
> mistakes will be made. That is why I prefer simpler formats.

Formats or syntaxes?  Let's be clear.

And yes, the fact that ASN.1 is relatively difficult to parse (but not
that difficult) has been used as an excuse to not use it or not write
tooling for it and just hand-code BER/DER coders.  But I think in
retrospect that it's not really the cause of the problem.  More likely
the fact that it was a non-free standard for so long meant that many
people coded to it without a proper understanding if it, much less
access to tools for it.  But that's ancient history now.  What about
the present?  Why not use this or that not-ad-hoc syntax?

> While I'm bashing ASN.1, formats that allow infinite length data items are
> asking for buffer overruns.

Like JSON?  Parsers/decoders need to impose some reasonable limits.
But this is not where the buffer overflows come from.  The buffer
overflows I think you're thinking of mostly resulted from redundancy
in TLV encodings.

Nico
--

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 18 Jun 2013 20:22:31 -0400

Bill,

For the software I was talking about - it is finish now, not the start. It's been deployed on multiple platforms since 1995 (testing the code included procedure currently called "fuzzing" :). And survived unscathed for several years that I tracked it. Decommissioned by now, I suspect, undefeated as far as I know.

So while I admire the skepticism expressed below, it probably could find a better application. ;).  Not all the computer security is born equal. :)

MIT LL Root CA: 

----- Original Message -----
From: Bill Frantz [mailto:[email-masked]]
Sent: Tuesday, June 18, 2013 07:05 PM
To: Blumenthal, Uri - 0558 - MITLL
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [TLS] TLS grammar checker?

[More inline]

Cheers - Bill

---

From: [email-masked] (Martin Rex)
Date: Sat, 22 Jun 2013 01:33:25 +0200 (CEST)

Nico Williams wrote:
> > [email-masked] (Blumenthal, Uri - 0558 - MITLL) wrote:
> >>

Syntax that is so complicated that it needs tooling is a problem by itself.
ASN.1 is squarely part of the problem space, not part of the solution space.

If you believe you can parse or encode X.509/PKIX just by using an
ASN.1 compiler tooling, then you probably have never even looked
at X.509/PKIX.  The devil is in the comments sprinkeled all over the
place where you have to tweak the compiler output in so many ways and
so many places that writing everything by yourself becomes quite a
viable alternative, and one that is free of hidden eastereggs.

While there exist a canonical ASN.1 DER encoding, decoding and re-encoding
Certificates and CRLs may often result in digital signature verification
failures.

Dealing e.g. with the Version field of CRLs in particularly entertaining:

   TBSCertList  ::=  SEQUENCE  {
        version                 Version OPTIONAL,
                                     -- if present, MUST be v2

Look at what rfc5280 says about the CRL version field:

 http://tools.ietf.org/html/rfc5280#section-5.1.2.1

   5.1.2.1. Version

   This optional field describes the version of the encoded CRL.  When
   extensions are used, as required by this profile, this field MUST be
   present and MUST specify version 2 (the integer value is 1).

and then check the real world what today's CRLs look like:

 o The CRL from the CRL-DP of the Google Internet Authority
   (the CA that signs Google's Server certs, including https://www.google.com)
   http://crl.geotrust.com/crls/secureca.crl

   no Version field (and no CRL extensions)

 o The CRL from the CRL-DP of the VeriSign Class3 EV SSL SGC CA
   (the CA that signed https://www.verisign.com/)

   http://EVSecure-crl.verisign.com/pca3-g5.crl

   no Version field (and no CRL extensions)

 o The CRL from the CRL-DP of the Godaddy Secure CA
   (the CA that signed https://www.godaddy.com/)

   http://certificates.godaddy.com/repository/gdroot.crl

   no Version field (and no CRL extensions)

Now the question for the implementor what to accept:

  1) reject (=soft fail and ignore) all three CRLs above ?
  2) reject all CRLs that have an explicit Version v1 (0) ?
  3) reject all CRLs that have no Version field,
     but non-critical CRL extensions (this is explicitly allowed by X.509!!)

ASN.1 is more than enough rope to hang yourself, and a number of existing
specs that use ASN.1, hang themselves in more than one place.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Jun 2013 19:17:20 -0500

> Syntax that is so complicated that it needs tooling is a problem by itself.

*All* useful syntax (in this space) is useful because you can you can
build tooling around it.  By definition, then, it requires tooling.

ASN.1 is not easy to parse, but it's not terribly hard either.
There's at least three, maybe four open source compilers.  And there
would have been many more had ASN.1 been *free* back in the 80s.

That's ASN.1's biggest sin: it wasn't free.  If you say it's mostly
unknown, well, that's partly why.

ASN.1's next biggest sin: its crappy initial encoding rules (BER, DER, and CER).

If I could go back in time and do anything about this it'd be: tell
people in the 80s about JSON (with chunked, unescaped string
encoding).

> ASN.1 is squarely part of the problem space, not part of the solution space.

Anything with tooling is in the solution space.  Today I prefer JSON
(see above).

> viable alternative, and one that is free of hidden eastereggs.

These are the results of ASN.1 having been non-free.  The same applies
to Kerberos.

> Certificates and CRLs may often result in digital signature verification

The universal consensus seems to be: don't do that [regardless of
encoding].  This has come up again and again, in the context of ASN.1,
XML, and JSON, and the answer is always: don't bloody do that.

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Sat, 22 Jun 2013 03:32:31 +0200 (CEST)

Nico Williams wrote:
> Martin Rex <[email-masked]> wrote:
> > Nico Williams wrote:

The beauty of the TLS syntax is, that it can be briefly explained
inside the spec and all an implementor ever needs is the protocol
spec itself.

It's a similar reason why DEK's choice of MIX assembly language for his
TAOCP book series is a very reasonable choice of a programming language.

Going back to my original question, whether implementations should
accept a GeneralizedTime with a 2-digit year -- I just forged myself
certs with a lame validity->notafter, and here are the results:

(1) "490101120101Z" tagged as UNIVERSAL 24 (aka GeneralizedTime) 

   OpenSSL 0.9.8l, 1.0.0d and 1.0.1c show     "Jan 12 01:01:00 4901 GMT"
   Microsoft CryptoAPI (Win2K3 and Win7) show "Jan 12 01:01:00 4901 GMT"
   Google Chrome 27 on Win7 accepts it (shows MS-CryptoAPI cert wizard)
   Firefox 3.6.28 and 21.0               show "Jan 12 01:01:00 4901 GMT"

(2) "20510101120101.1Z" tagged as UNIVERSAL 24 (aka GeneralizedTime)

   OpenSSL 0.9.8l show                        "Jan  1 12:01:01 2051 GMT"
   OpenSSL 1.0.0d and 1.0.1c show             "Jan  1 12:01:01.1 2051 GMT"
   Microsoft CryptoAPI (Win2K3 and Win7) show "Jan  1 12:01:01 2051 GMT"
   Google Chrome 27 on Win7 accepts it (shows MS-CryptoAPI cert wizard)
   Firefox 3.6.28 and 21.0 reject it "sec_error_invalid_time"
   
(3) "20510101120101Z" tagged as UNIVERSAL 23 (aka UTCTime)

   OpenSSL 0.9.8l, 1.0.0d and 1.0.1c reject input
   Microsoft CryptoAPI (Win2K3 and Win7) reject input

(1) would hardly interop, so rejecting it entirely seems OK.

(2) rejecting it should be OK. I would not have expected so much acceptance.

While this doesn't really answer the question for OCSP, the
results in (1) hints that this like would have already caused problems
if OCSP responders would be straight copying rather than converting the Time
values from CRLs into GeneralizedTime values of OCSP responses.

-Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 22 Jun 2013 10:03:32 -0400

> The beauty of the TLS syntax is, that it can be briefly explained inside the spec and all an implementor ever needs is the protocol spec itself.

Really?  Can I have a vector of digitally-signed?

> Going back to my original question, whether implementations should accept a GeneralizedTime

That's an IETF question, not an ASN.1 question.  ASN1 says quite clearly that those years are four-digit.  Did they get everything right on the first publication?  Certainly not.  Heck, even the IETF has errata :)

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 24 Jun 2013 16:37:28 +0000

From: Nico Williams

> ASN.1's next biggest sin: its crappy initial encoding rules (BER, DER, and CER).

Beauty is in the eye of the beholder.  The self-describing properties of TLV encodings like BER are often useful, providing a middle ground between highly optimized binary encodings (PER) that cannot be parsed without the data definition and bulky ASCII encodings (JSON) that are readable with a text editor.

> Anything with tooling is in the solution space.  Today I prefer JSON (see above).

+1.  Anyone up for defining JER?  :-)

>> ASN.1 compiler tooling, then you probably have never even looked at 
>> X.509/PKIX.  The devil is in the comments sprinkeled all over the 
> These are the results of ASN.1 having been non-free.  The same
> applies to Kerberos.

SNMP seems to have done ASN.1 the right way - adopting a simple subset of needed features and eschewing the esoteric.  I take the same approach with my Sony digital camera - it has zillions of ridiculous picture-taking features including, believe it or not, "food mode".  Yet I manage to get by with just the basic four: P, S, A, and M.

ASN.1's extensive feature set deserves at least as much blame as its non-freeness.  But spec writers (including myself) deserve the bulk of the criticism for not exercising craftsmanship and self-restraint.  Just because the features exist doesn't mean they have to be used.  TLS could be written in SNMP-ASN.1 without requiring compiler tweaking.

> Also: Amiga over Atari.

You're in the right processor family.  6502 >> 8080.