Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 18 June 2019 01:23 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D2212034F; Mon, 17 Jun 2019 18:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.436
X-Spam-Level: *
X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 5hMVyqCSxGyE; Mon, 17 Jun 2019 18:23:48 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4D6120344; Mon, 17 Jun 2019 18:23:47 -0700 (PDT)
Received: from dooku.sandelman.ca (static-68-179-115-177.ptr.terago.net [68.179.115.177]) by relay.sandelman.ca (Postfix) with ESMTPS id 879651F450; Tue, 18 Jun 2019 01:23:45 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 0D69948CE; Mon, 17 Jun 2019 21:23:29 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Anima WG <anima@ietf.org>, spasm@ietf.org
In-reply-to: <f2403f8d-f40b-3112-cd23-cde9ae04a74b@gmail.com>
References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <F896BCBC-6C32-4107-B4B5-C12617F81326@tzi.org> <AD4DC1AA-C332-4BC7-B095-0CDD30700B99@cisco.com> <909.1560436148@localhost> <BN7PR11MB25473A12F646FAC8C19C1118C9EF0@BN7PR11MB2547.namprd11.prod.outlook.com> <8921.1560788417@dooku.sandelman.ca> <BN7PR11MB2547DFFF1EC4B7B92D0FC9DDC9EB0@BN7PR11MB2547.namprd11.prod.outlook.com> <f2403f8d-f40b-3112-cd23-cde9ae04a74b@gmail.com>
Comments: In-reply-to Brian E Carpenter <brian.e.carpenter@gmail.com> message dated "Tue, 18 Jun 2019 08:44:43 +1200."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 17 Jun 2019 21:23:29 -0400
Message-ID: <10970.1560821009@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/rcPgFcQjKY9miiUTm5OKq9Ps5BI>
Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2019 01:23:50 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    > On 18-Jun-19 05:18, Panos Kampanakis (pkampana) wrote:
    >>> So effectively, the CTE header has effectively been dropped, but the
    >>> payload is now assumed to be base64, regardless.  This suggests that
    >>> we can not use the CTE header as a signal.

    > I went and looked at RFC4648 for my own education, and then spent a few
    > minutes trying to design a Turing machine that can distinguish a binary
    > bit string from a base64 bit string. Fail. You can determine that a bit
    > string is definitely not base64 if it contains at least one character
    > outside the base64 alphabet, but not the converse. So it needs a
    > signal. Not having a signal would be wide open to malicious misuse,
    > IMHO. Indicating the length of the payload would be enough, I think.

So I conclude that we can't patch RFC7030.

We can drop the Content-Transfer-Encoding headers (and it seems that many
have done that anyway), but we are stuck with a base64 encoded payload for
the four end-points that 7030 describes.

We could create new end-points that are not base64 encoded, but that does not
seem that important.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-