IETF Logo Mail Archive

Re: [core] đź”” WGLC on draft-ietf-core-object-security

Mališa Vučinić <malisa.vucinic@inria.fr> Thu, 14 December 2017 13:18 UTC

Return-Path: <malisa.vucinic@inria.fr>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4F1126C25; Thu, 14 Dec 2017 05:18:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] 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 1HhPZ4fw2Fz7; Thu, 14 Dec 2017 05:18:07 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 9722B124205; Thu, 14 Dec 2017 05:18:06 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.45,400,1508796000"; d="scan'208,217";a="305473148"
Received: from unknown (HELO [192.168.1.3]) ([89.188.33.128]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 14:18:04 +0100
From: Mališa Vučinić <malisa.vucinic@inria.fr>
Message-Id: <CA57CC47-05E7-4200-9A88-6AD86BF7E204@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9F79A59E-E2B0-4213-8F06-D17B9DBBA9B4"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 14 Dec 2017 14:18:03 +0100
In-Reply-To: <59F07A9C-B5E4-4EA0-96D6-A425F132F56B@ericsson.com>
Cc: "draft-ietf-core-object-security.authors@ietf.org" <draft-ietf-core-object-security.authors@ietf.org>
To: "core@ietf.org WG (core@ietf.org)" <core@ietf.org>
References: <59F07A9C-B5E4-4EA0-96D6-A425F132F56B@ericsson.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/r63t6E3baIlEtcRQ0jSvpGlNfpk>
Subject: Re: [core] đź”” WGLC on draft-ietf-core-object-security
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
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, 14 Dec 2017 13:18:10 -0000

Göran, all,

It was really a pleasure to witness how this spec advanced from draft-selander-ace-object-security-00 and evolved to its current form. Thank you for accommodating the requests coming from 6TiSCH and making this solution so efficient.

I am just starting to work on a Wireshark dissector and this made me go through the text on HTTP-to-CoAP and CoAP-to-HTTP proxying as one may have HTTP carrying OSCORE. I would like to understand better the added value of this part of the spec. Take as an example HTTP client generating request that is proxied/translated into a CoAP request. For the HTTP client to generate external_aad and ciphertext, it needs to implement portions of CoAP machinery. For example, to generate plaintext, the HTTP client needs to know in advance what CoAP Code will the proxied request have, how HTTP headers will translate to CoAP options and how to encode them in CoAP format. My question is whether it makes sense for an HTTP client to implement this, but not the rest of CoAP.

Second comment is related to normative language on error handling in -07. Background: Some error responses can be spoofed as they are not protected due to the lack of common keying material, so this opens up a DoS vector on the client. Current text in -07 states that the server MAY send this kind of response. Could you elaborate the reasoning behind this? What is the expected behavior of a client? Could you discuss somewhere security tradeoff being made when one opts for one approach or the other? Why do you not differentiate based on message type (NON/CON), as used in previous versions?

Mališa


> On 20 Nov 2017, at 16:09, Jaime Jiménez <jaime.jimenez@ericsson.com> wrote:
> 
> Dear CoRE WG,
> 
> As we discussed during this IETF, the OSCORE draft is in good shape for WGLC. 
> The authors have submitted a reviewed version dealing with the minor comments from IEF100.
> 
> https://tools.ietf.org/html/draft-ietf-core-object-security-07 <https://tools.ietf.org/html/draft-ietf-core-object-security-07> 
> 
> The WGLC will end by 11th of December. 
> 
> Best Regards,
> - - Jaime Jiménez
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

v2.23.0 | Report a Bug | By Email