Re: [TLS] TLS grammar checker?

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Wed, 19 June 2013 00:22 UTC

Return-Path: <prvs=9882fcc32e=uri@ll.mit.edu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1462E21E80A5 for <tls@ietfa.amsl.com>; Tue, 18 Jun 2013 17:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.035
X-Spam-Level:
X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9Vd7ycV-LiI for <tls@ietfa.amsl.com>; Tue, 18 Jun 2013 17:22:39 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6912B11E811A for <tls@ietf.org>; Tue, 18 Jun 2013 17:22:34 -0700 (PDT)
Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r5J0MWYF009664; Tue, 18 Jun 2013 20:22:32 -0400
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: "'frantz@pwpconsult.com'" <frantz@pwpconsult.com>
Date: Tue, 18 Jun 2013 20:22:31 -0400
Thread-Topic: [TLS] TLS grammar checker?
Thread-Index: Ac5sgLnolRtlFZhDTJuVj8NrdxGchAAAlppW
In-Reply-To: <r422Ps-1075i-3AFF88CCA21845BB9D2515C6C2709DA6@Williams-MacBook-Pro.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-18_09:2013-06-18, 2013-06-18, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1306180266
Message-Id: <20130619002237.6912B11E811A@ietfa.amsl.com>
Cc: "'tls@ietf.org'" <tls@ietf.org>
Subject: Re: [TLS] TLS grammar checker?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2013 00:22:44 -0000

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. :)

--
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: Bill Frantz [mailto:frantz@pwpconsult.com]
Sent: Tuesday, June 18, 2013 07:05 PM
To: Blumenthal, Uri - 0558 - MITLL
Cc: 'nico@cryptonector.com' <nico@cryptonector.com>; 'tls@ietf.org' <tls@ietf.org>; 'frantz@pwpconsult.com' <frantz@pwpconsult.com>
Subject: Re: [TLS] TLS grammar checker?

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, uri@ll.mit.edu (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: <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*.

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
>TLS@ietf.org
>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