Re: [TLS] TLS grammar checker?

Nico Williams <nico@cryptonector.com> Sat, 22 June 2013 00:17 UTC

Return-Path: <nico@cryptonector.com>
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 6D40521E809E for <tls@ietfa.amsl.com>; Fri, 21 Jun 2013 17:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.96
X-Spam-Level:
X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 0b1RP9YI3fjK for <tls@ietfa.amsl.com>; Fri, 21 Jun 2013 17:17:23 -0700 (PDT)
Received: from homiemail-a84.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFDE11E80C5 for <tls@ietf.org>; Fri, 21 Jun 2013 17:17:23 -0700 (PDT)
Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id DDC171DE058 for <tls@ietf.org>; Fri, 21 Jun 2013 17:17:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=CVLkgfnRGtvpmhHa/o5r T33iLjs=; b=YL+37wOkWylQ2WQb5uQZ8aXN4DlCqztDChzGh5F1pU6bBiOZ/PXb TRJYmw/arfFlxXU+5ShRmIgbW5XSu0mrUkZsupDNCCxNXx8oPbLrwh1cs99/WhrQ 2x1cbCtjRsoZCZAa2C62R+skzrg4YFsfdZy4XjdDboh6ziYbfNRsKjs=
Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 8F2F21DE005 for <tls@ietf.org>; Fri, 21 Jun 2013 17:17:22 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id n57so6960386wev.0 for <tls@ietf.org>; Fri, 21 Jun 2013 17:17:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vvjZSsAeE+Jha9a0UyH+0Jq8mnLueOX/ZMzrJ1Cu3zU=; b=QCcC6DQeuqGMGJmvdAh045FC6RTqLj5H2WJXr1ecjAI56yRxE/fPe8m/oAGRJqGIo7 By5CiITMlU1JC/Sukx+Wrj+uW+yc8i8aYuxyaVSVcqcDYNij6pmTIGN5C0SPVMwuLyXT sQTaYUX4sRhZkrzxoyc6x9FeHowkMwIz0uhDUcWe4q/Tv8MEsuAAI93RTQCBqEbBwq2p Sljs4VEh0+ucznCjFMmN+RvrFeWdn4F5R+R4yB5RyEs/Zoplz9tE70Mwk12RFf/mMW3J hNOkHKjMgbLCTdZS7l1MK/8mU0OS+PdMzKBj4/N4y4oTzp/t7kWLZBp5lyBgG+V2D6sT H+3Q==
MIME-Version: 1.0
X-Received: by 10.180.107.163 with SMTP id hd3mr388750wib.13.1371860241073; Fri, 21 Jun 2013 17:17:21 -0700 (PDT)
Received: by 10.216.29.5 with HTTP; Fri, 21 Jun 2013 17:17:20 -0700 (PDT)
In-Reply-To: <20130621233326.03E831A842@ld9781.wdf.sap.corp>
References: <CAK3OfOj82obkjVipLxsn_yfwA_YnT-J1n0orJj9p00X5s3v26g@mail.gmail.com> <20130621233326.03E831A842@ld9781.wdf.sap.corp>
Date: Fri, 21 Jun 2013 19:17:20 -0500
Message-ID: <CAK3OfOjX0fH+JDXB8vOr_A_on+nzvMW=u4LxQwSc-pMq_7s9eQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: mrex@sap.com
Content-Type: text/plain; charset="UTF-8"
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: Sat, 22 Jun 2013 00:17:28 -0000

On Fri, Jun 21, 2013 at 6:33 PM, Martin Rex <mrex@sap.com> wrote:
> Nico Williams wrote:
>> 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.
>
> 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).

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

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

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

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
--