Re: [TLS] TLS grammar checker?

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: <uri@ll.mit.edu>
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:nico@cryptonector.com]
Sent: Tuesday, June 18, 2013 05:49 PM
To: Bill Frantz <frantz@pwpconsult.com>
Cc: tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] TLS grammar checker?

On Tue, Jun 18, 2013 at 5:20 PM, Bill Frantz <frantz@pwpconsult.com> wrote:
> On 6/18/13 at 10:36 AM, nico@cryptonector.com (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*.

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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls