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

"Jim Schaad" <ietf@augustcellars.com> Fri, 29 January 2016 19:46 UTC

Return-Path: <ietf@augustcellars.com>
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 957471B3295; Fri, 29 Jan 2016 11:46:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 QsPbkEPOfDct; Fri, 29 Jan 2016 11:46:22 -0800 (PST)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1FD1B3299; Fri, 29 Jan 2016 11:46:22 -0800 (PST)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id E3B272C9BB; Fri, 29 Jan 2016 11:46:21 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Carsten Bormann' <cabo@tzi.org>
References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> <D27C68A8.3F21C%goran.selander@ericsson.com> <063a01d15a22$24099250$6c1cb6f0$@augustcellars.com> <56AB166F.9040404@tzi.org>
In-Reply-To: <56AB166F.9040404@tzi.org>
Date: Fri, 29 Jan 2016 11:43:47 -0800
Message-ID: <06d301d15acd$5f37c120$1da74360$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AQH/N40dZG+wyPslqrIqOShIBqjspwKyJuasAbm/U5kA9GZ54p6MKAIg
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/s4VuZJZKDnnIo6WKyPhcAvJiEC0>
Cc: ietf@ietf.org, core@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: Fri, 29 Jan 2016 19:46:24 -0000


> -----Original Message-----
> From: Carsten Bormann [mailto:cabo@tzi.org]
> Sent: Thursday, January 28, 2016 11:36 PM
> To: Jim Schaad <ietf@augustcellars.com>
> Cc: ietf@ietf.org; core@ietf.org
> Subject: Re: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers
> in CoAP) to Proposed Standard
> 
> Hi Jim,
> 
> great discussion, thank you.
> Retroactively adding security over insecure channels to CoAP is not an area with
> easy answers.
> 
> A couple of random observations:
> 
> -- indeed, block is meant to help getting larger messages through the network.
> The individual blocks are generally not really worth individual protection.  I think
> the biggest remaining question with this is what to do against an attacker
> polluting a cache with a bad block (creating a problem for availability, not
> integrity).  (In RFC7252's security model, DTLS prevents that from happening.)
> 
> -- in CoAP, options are given option numbers that expose some of their
> characteristics, e.g., critical/elective, safe-to-forward, cache-key, so some
> operations are possible on options that the system handling them doesn't know.
> We didn't think to have bits in the option number for the security properties of
> the option.  Can we possibly derive everything we need from the existing bits?
> Do we maybe have to carry that information separately with a message secured
> at the CoAP level?

This is not dealing with the issue that I raised.  Consider the following case

In block 1, the content type is set to 1.
In block 2, the content type is set to 2.

Now, this can be an error.  This can be a use the first value.  This can be a use the last value.

Which of the above three cases should I evaluate to on the base protocol.  Nothing to do with security.

The same question arises when if content type is absent in block2. 

There are going to be some item which can and will change.  This are probably the unsafe to forward items.  The behavior might change based on some type of criticality bit in the option number.   This should be documented in the core protocol.

Jim

> 
> -- A small group is working on classifying the desirable security objectives for the
> existing CoAP options.  That is not an easy project, but I hope we will have
> something to look at for Buenos Aires.
> 
> -- As a random coincidence, have a look at the new
> https://tools.ietf.org/html/draft-thomson-http-mice-00
> 
> Grüße, Carsten