Re: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers in CoAP) to Proposed Standard

Carsten Bormann <cabo@tzi.org> Thu, 26 November 2015 08:08 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E45D1B3608; Thu, 26 Nov 2015 00:08:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=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 WodIabZoA7fg; Thu, 26 Nov 2015 00:08:51 -0800 (PST)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03E51B3607; Thu, 26 Nov 2015 00:08:50 -0800 (PST)
Received: from mfilter29-d.gandi.net (mfilter29-d.gandi.net [217.70.178.160]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 29CC541C08F; Thu, 26 Nov 2015 09:08:49 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter29-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter29-d.gandi.net (mfilter29-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id eJhgIHvOkP4e; Thu, 26 Nov 2015 09:08:47 +0100 (CET)
X-Originating-IP: 93.199.254.229
Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id B4C1E41C08D; Thu, 26 Nov 2015 09:08:37 +0100 (CET)
Message-ID: <5656BE03.3090604@tzi.org>
Date: Thu, 26 Nov 2015 09:08:35 +0100
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Göran Selander <goran.selander@ericsson.com>
References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> <D27C68A8.3F21C%goran.selander@ericsson.com>
In-Reply-To: <D27C68A8.3F21C%goran.selander@ericsson.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/w2xOdEhYYcTAj9uxXCF2aPVM8lg>
Cc: "core-chairs@ietf.org" <core-chairs@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "core@ietf.org" <core@ietf.org>, "barryleiba@gmail.com" <barryleiba@gmail.com>, "draft-ietf-core-block@ietf.org" <draft-ietf-core-block@ietf.org>
Subject: Re: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers in CoAP) to Proposed Standard
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2015 08:08:52 -0000

Göran Selander wrote:
> we should
> not ignore these security issues in new standards.

Definitely, we shouldn't ignore these security issues when defining new
standards.

Now why is this a comment on the IETF last-call for an existing
specification?  It's not like Block was invented yesterday and people
are still figuring out how to implement it.  For years, it has actually
been part of a number of specifications that were derived from the CoAP
specifications.  It isn't very likely that spending another year or two
on finding out what specific mandates on proxies might possibly make
life a bit easier for a new object security specification would have any
influence on today's CoAP implementations.

When you have found out what is needed, write what you need into that
object security specification.  Document the level of backwards
compatibility achieved (hint: You may want to carefully define your
objectives here).  (And don't forget that you should be solving the
problem for cross-protocol proxies as well.)

Grüße, Carsten <not wearing chair hat today because I happen to be the
author of that specification>