Re: [TLS] TLS grammar checker?

[Bill Frantz <[e-mail]>]

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, [e-mail] (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: [phone]
>Cyber Systems and Technology   Fax:   [phone]
>MIT Lincoln Laboratory                Cell:  [phone]
>244 Wood Street                        Email: <[e-mail]>
>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:[e-mail]]
>Sent: Tuesday, June 18, 2013 05:49 PM
>To: Bill Frantz <[e-mail]>
>Cc: [e-mail] <[e-mail]>
>Subject: Re: [TLS] TLS grammar checker?
>
>On Tue, Jun 18, 2013 at 5:20 PM, Bill Frantz <[e-mail]> wrote:
>>On 6/18/13 at 10:36 AM, [e-mail] (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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls
>
-----------------------------------------------------------------------
Bill Frantz        | I don't have high-speed      | Periwinkle
[phone]      | internet. I have DSL.        | 16345 
Englewood Ave
www.pwpconsult.com |                              | Los Gatos, 
CA 95032