Re: [ANNOUNCE] new release of the ParrotTalk protocol specification, version 3.7

Carsten Bormann <cabo@tzi.org> Wed, 21 November 2018 16:31 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C835E128AFB for <ietf@ietfa.amsl.com>; Wed, 21 Nov 2018 08:31:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fze2h6NZFAPV for <ietf@ietfa.amsl.com>; Wed, 21 Nov 2018 08:31:48 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A87C130DCA for <ietf@ietf.org>; Wed, 21 Nov 2018 08:31:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wALGVcgF023990; Wed, 21 Nov 2018 17:31:43 +0100 (CET)
Received: from [192.168.217.114] (p54A6CE66.dip0.t-ipconnect.de [84.166.206.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 430Sky4TDMz1Bqf; Wed, 21 Nov 2018 17:31:38 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: [ANNOUNCE] new release of the ParrotTalk protocol specification, version 3.7
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <c4Q4L5o9q57cegtvu6-TJHQnWk6TQ1viHoFm4gDiZCWVEHCZkZtJp2wqy8xwlaud8ND1vfwTM1sZglurtvhonqVhyJ29-TeGZ3BcawFZegs=@pm.me>
Date: Wed, 21 Nov 2018 17:31:37 +0100
Cc: IETF discussion list <ietf@ietf.org>
X-Mao-Original-Outgoing-Id: 564510693.311101-1768a77ee1265687c81f3470364bdadc
Content-Transfer-Encoding: quoted-printable
Message-Id: <794F6995-C3A7-4F8E-9731-A63FEE7B476F@tzi.org>
References: <SyrakryPyk1zzTAO_b_NyUPXPt4l3W1m9vt55Lg1m7sHhi1fi2TCmIbQCH5pqFtPpvR4rFWm-6DxNCGTCN7rSMBmGMnRSVx6v5xu_z2kKDI=@protonmail.com> <CAPt1N1n_kzQyeoy_fXKz3BLjiUYqWq2J9sm4=0STjeX51H+yjw@mail.gmail.com> <c1cFwZUvofxtc2Y63oyZ8Cz9iX3tT9IlAdPVAD-sfOh-fUy4sFXV9WEpO_tp7hownBT__us64FXidemK1QnrxGlShvK66z39f7ReNGj-j5s=@protonmail.com> <CABcZeBN64hbJ-hp+7Q9pzX+u0nv6Fiq0XYY_v22EB_no23Cy2A@mail.gmail.com> <c4Q4L5o9q57cegtvu6-TJHQnWk6TQ1viHoFm4gDiZCWVEHCZkZtJp2wqy8xwlaud8ND1vfwTM1sZglurtvhonqVhyJ29-TeGZ3BcawFZegs=@pm.me>
To: Robert <robert.withers@pm.me>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/EMsT5qhTtxOSR3gXYOxCCUmXRqo>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Nov 2018 16:31:51 -0000

Hi Robert,

maybe adding to all the good comments that Eric Rescorla gave, this one statement stuck out for me:

> On Nov 21, 2018, at 12:34, Robert <robert.withers=40pm.me@dmarc.ietf.org> wrote:
> 
> strong advantage is that all the headers used in the message flow are defined as ASN1 structures

There are quite a few people who would perceive this as a disadvantage.  ASN.1 (or X.409, as it was called then) was a great new idea in 1983, but 35 years later we now know more about its downsides (and, not to forget, those of its dominating set of encoding rules, BER).  If you want to stay close to the PKI, it may seem natural to continue to use it, but it seems you count freedom from X.509 certificates as a feature, and that would bring you closer to newer formats such as CBOR and COSE (RFC 8152), which you may want to look at.

Obviously, representation formats are much less important than the security properties of the protocol itself, which I cannot comment on as I haven’t seen it.  They still can be an important factor in implementation stability and interoperability, as we have for example experienced when ASN.1 helped sink H.323 some 20 years ago.  But there is also a security aspect, which you can gauge by counting the number of CVEs that mention ASN.1 decoder implementations.

Grüße, Carsten