Re: [Ace] FW: New Version Notification for draft-selander-ace-object-security-05.txt

Marco Tiloca <marco@sics.se> Tue, 12 July 2016 09:26 UTC

Return-Path: <marco@sics.se>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B92C12B010 for <ace@ietfa.amsl.com>; Tue, 12 Jul 2016 02:26:15 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics-se.20150623.gappssmtp.com
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 TMfCtqdENCAz for <ace@ietfa.amsl.com>; Tue, 12 Jul 2016 02:26:12 -0700 (PDT)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2101312D75F for <Ace@ietf.org>; Tue, 12 Jul 2016 02:26:12 -0700 (PDT)
Received: by mail-vk0-x232.google.com with SMTP id o63so13478656vkg.1 for <Ace@ietf.org>; Tue, 12 Jul 2016 02:26:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s8WjU17rkbgWcbhWF/iqD45FCSmJZBXiggvKjh8MN0k=; b=hK2W7QBS/frfFTwzRQiDFYFwl7u5zkb4FgghBn+CVACpnpnTcXBMXSlSBNxRImSASG FdEBn9Y8eLG2biFzJqgK1x3xbyHGap3asdVYu9oWFfylVGZwlceR7EvnGzPqECHcARBV zNCZXqmMAZMdBp/N//oc3qxsB+ecgBwDTVhWiQdN69faEwnS5z0qJ+lWbnMafkv/0HPC nH3tCn1blMmkaklTuqEaey3Q7u+Eub4/1Z4QaKENzH+zPw0zAK6UKS57lePTNxEAWiFr 52JPZMHpC41UOjbufVGDJgwFHgJmLX9pbVo9S2pswWO8DYmDI0Ga6ZeQHAccEQcW8lA2 iBNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s8WjU17rkbgWcbhWF/iqD45FCSmJZBXiggvKjh8MN0k=; b=jDvoUN7HqjNNANcQOtCITmFfhZerDAn1KLNgpnJXCIVS2XJ0l/kRnbLbnInvAbYO+S mAwWlO6tzlRTs8MsLgi18LkQBcSiE0MG2Tl8+GuTszRs+tiOny4wiHDlSXH1RvybQL4e HvlZPLSRt+U/mWnraX97bos9T85YLEwvU/71V0i2Ak5axPNJkOaqZfJFjFBzjFQPHq0+ llDn8prptOxaStv7t3Ss7CDkDge8rCf9zUzP4G+YkZofPNwPSjFcrGgJ7Zct7XvlWJrA BECG/jXve1eUGRAfBGnbVqdNwhVm0nQ8RxukUZCeOOUUrP+EO/8sfniJz9eOnPhdAgP6 zjYg==
X-Gm-Message-State: ALyK8tJsTvjEyjnkmlScMunKuMS10YmwAKlgP/DhREJhGnTcvDVNT14NFJlAJ177MnqCOjb89C3MAV553i64TZrk
X-Received: by 10.31.129.203 with SMTP id c194mr486513vkd.26.1468315571136; Tue, 12 Jul 2016 02:26:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.87.74 with HTTP; Tue, 12 Jul 2016 02:26:10 -0700 (PDT)
In-Reply-To: <AMXPR07MB070FAF73F930DEF19972C8698300@AMXPR07MB070.eurprd07.prod.outlook.com>
References: <20160707163729.23634.20152.idtracker@ietfa.amsl.com> <AMXPR07MB0709A19CD21050F2B2DC7F4983C0@AMXPR07MB070.eurprd07.prod.outlook.com> <CABFpCtCnaMvLiAN=gJJPJSgxV5+=KWG8LGj5WK0kvvrUpSHyMA@mail.gmail.com> <AMXPR07MB070FAF73F930DEF19972C8698300@AMXPR07MB070.eurprd07.prod.outlook.com>
From: Marco Tiloca <marco@sics.se>
Date: Tue, 12 Jul 2016 11:26:10 +0200
Message-ID: <CABFpCtCoGpHnfpFMgLu4zhh0EsBu3Qb-X=zh0DFd0hQm=d1fJQ@mail.gmail.com>
To: Francesca Palombini <francesca.palombini@ericsson.com>
Content-Type: multipart/alternative; boundary="001a1145037e09495805376cdc89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ChitxwYxxZ0Cibx9MjC6zopvPsg>
Cc: "Ace@ietf.org" <Ace@ietf.org>, "core@ietf.org" <core@ietf.org>, "cose@ietf.org" <cose@ietf.org>
Subject: Re: [Ace] FW: New Version Notification for draft-selander-ace-object-security-05.txt
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2016 09:26:16 -0000

Hi Francesca,

On Tue, Jul 12, 2016 at 10:14 AM, Francesca Palombini <
francesca.palombini@ericsson.com> wrote:

> Hi Marco,
>
>
>
> Thank you so much for an extended review! I agree with all your comments
> and I think they will improve the readability of the draft.
>
> I just have a question for 1):
>
>
>
> We introduce the use of COSE objects already in Section 1. Introduction,
> in the last paragraph of page 3 (“OSCOAP builds on CBOR Object Signing and
> Encryption (COSE) …”). Was there a reason why you wanted it mentioned in
> the Object Security option section, specifically?
>

I suggested that just for the sake of readability. The COSE object is
introduced in Section 1, but then I thought about a reader starting
directly from the actual specification in Section 2, where the COSE object
"suddenly reappears" at the end of page 5, and is of course detailed only
later in Section 5.

This is why I believe it would be good to quickly mention again the usage
of COSE objects at the beginning of Section 2, just from a high-level
perspective as in the Introduction and also pointing to Section 5 for
further details, so better preparing the reader for the 2-element bullet
list at the end of page 5.

Best regards,
Marco


>
>
> Best,
>
> Francesca
>
>
>
>
>
> *From:* Marco Tiloca [mailto:marco@sics.se]
> *Sent:* den 11 juli 2016 16:11
> *To:* Francesca Palombini <francesca.palombini@ericsson.com>
> *Cc:* core@ietf.org; cose@ietf.org; Ace@ietf.org
> *Subject:* Re: [Ace] FW: New Version Notification for
> draft-selander-ace-object-security-05.txt
>
>
>
> Hello Francesca and all,
>
> I have reviewed this last version and I believe it is in a very good shape!
>
> Please, find below some suggestions for minor changes/updates.
>
> Best regards,
> /Marco
>
> ----------------------------
>
> 1) In Section 2, I would refer the usage of a COSE object as soon as
> possible, rather than at the end of page 5 where you describe how to
> prepare the protected CoAP message. For instance, the very first sentence
> in Section 2 can be followed by something like: "This is achieved by means
> of a COSE object included in the protected CoAP message, as detailed below".
>
> 2) In Section 2 (page 5), I would move the sentence "An endpoint receiving
> [...] treat it as malformed and reject it." at the end of the first element
> of the bullet list below, since it concerns CoAP messages with payload.
>
> 3) Following the same reasoning of point 2), I would extend the second
> element in the dotted list at the end of page 5 with: "An endpoint
> receiving a CoAP message without payload, that also contains an empty
> Object-Security option SHALL treat it as malformed and reject it".
>
> 4) Section 3.1, page 6, "The endpoint verifies the message received" -->
> "The endpoint verifies the messages received".
>
> 5) Section 5, page 13, add "(see Section 5.1)" after "is computed from the
> Plaintext", and "(see Section 5.2)" after "and the Additional Authenticated
> Data (AAD)".
>
> 6) Section 6.2, page 16, step 1. In the last sentences about renewing the
> security context on the client, it would be good to mention also that this
> involves informing the server, so that it can update its own Receiver-*
> parameters on its own context.
>
> 7) Section 6.2, page 16, step 2. "Store the MAC of each fragment" -->
> "Store the MAC of each last-sent fragment".
>
> 8) Section 6.3, page 17, step 2. "Store the MAC of each fragment" -->
> "Store the MAC of each last-received fragment".
>
> 9) Section 6.4, page 18, step 1. In the last sentences about renewing the
> security context on the server, it would be good to mention also that this
> involves informing the client, so that it can update its own Receiver-*
> parameters on its own context.
>
> 10) Section 6.4, page 18, step 2. "Store the MAC of each fragment" -->
> "Store the MAC of each last-sent fragment".
>
> 11) Section 6.5, page 19, step 2. "Store the MAC of each fragment" -->
> "Store the MAC of each last-received fragment".
>
> 12) Section 6.5, page 20, first paragraph. After the last sentence "DTLS
> and OSCOAP can be combined", I would restate what said in Section 1 (page
> 4), that is "thereby enabling end-to-end ..."
>
> 13) Section 6.5, page 20, third paragraph. "The use of COSE to protected
> CoAP messages" --> "The use of COSE to protect CoAP messages"
>
>
>
> On Fri, Jul 8, 2016 at 9:03 AM, Francesca Palombini <
> francesca.palombini@ericsson.com> wrote:
>
> Dear CoRE, COSE and ACE members,
>
> We have submitted an update to the OSCOAP draft:
> https://tools.ietf.org/html/draft-selander-ace-object-security-05
>
> For those who don’t know, OSCOAP is an application layer security protocol
> for CoAP, based on wrapping request and response messages in COSE objects
> which are sent in a CoAP message exchange.
>
> With this version, we aimed for improved readability and we added the
> blockwise functionality, as discussed during last f2f meeting.
>
> We are now looking for reviews. Any comment or feedback would be greatly
> appreciated!
>
> Best regards,
> Francesca
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: den 7 juli 2016 18:37
> To: Göran Selander <goran.selander@ericsson.com>; Ludwig Seitz <
> ludwig@sics.se>; John Mattsson <john.mattsson@ericsson.com>; Göran
> Selander <goran.selander@ericsson.com>; Francesca Palombini <
> francesca.palombini@ericsson.com>
> Subject: New Version Notification for
> draft-selander-ace-object-security-05.txt
>
>
> A new version of I-D, draft-selander-ace-object-security-05.txt
> has been successfully submitted by Francesca Palombini and posted to the
> IETF repository.
>
> Name:           draft-selander-ace-object-security
> Revision:       05
> Title:          Object Security of CoAP (OSCOAP)
> Document date:  2016-07-07
> Group:          Individual Submission
> Pages:          36
> URL:
> https://www.ietf.org/internet-drafts/draft-selander-ace-object-security-05.txt
> Status:
> https://datatracker.ietf.org/doc/draft-selander-ace-object-security/
> Htmlized:
> https://tools.ietf.org/html/draft-selander-ace-object-security-05
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-selander-ace-object-security-05
>
> Abstract:
>    This memo defines Object Security of CoAP (OSCOAP), a method for
>    application layer protection of message exchanges with the
>    Constrained Application Protocol (CoAP), using the CBOR Object
>    Signing and Encryption (COSE) format.  OSCOAP provides end-to-end
>    encryption, integrity and replay protection to CoAP payload, options,
>    and header fields, as well as a secure binding between CoAP request
>    and response messages.  The use of OSCOAP is signaled with the CoAP
>    option Object-Security, also defined in this memo.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>
>