Re: [Ace] draft-ietf-ace-coap-est-00

peter van der Stok <> Mon, 12 March 2018 08:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C25B1270AB; Mon, 12 Mar 2018 01:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hRbKWEIAqLUu; Mon, 12 Mar 2018 01:08:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F181D12706D; Mon, 12 Mar 2018 01:08:07 -0700 (PDT)
Received: from ([IPv6:2001:888:0:22:194:109:20:200]) by with ESMTPA id vIV3eG5kW8U07vIV3eXoPZ; Mon, 12 Mar 2018 09:08:06 +0100
Received: from 2001:983:a264:1:5ddc:c088:1025:584f by with HTTP (HTTP/1.1 POST); Mon, 12 Mar 2018 09:08:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Mon, 12 Mar 2018 09:08:05 +0100
From: peter van der Stok <>
To: Jim Schaad <>
Organization: vanderstok consultancy
In-Reply-To: <001d01d3b8b4$f6e71600$e4b54200$>
References: <001d01d3b8b4$f6e71600$e4b54200$>
Message-ID: <>
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfGb+n0f6n7EkWPGM4+G4hh07WSjPrf+E1g07JwsCq5G7g9t/oEuS8BuL7osZsRkPOmpchSle4siAZKkVNas+MALhO1HUTZGlZMddd6G8iMBopp8UNhd/ dxOj3IprKu4bjzqFF7tntMq8LcN5nG353MnlU2hA2BIkiJjy4TpMJ3ccvmCa2nAIGIVEXBrAuQnzdh8F7nsJYfDXZKAwOsaIN1DVIuicjI4PQWtvuNlYllEx 6lp5698K+h/lfFDlO68o3w==
Archived-At: <>
Subject: Re: [Ace] draft-ietf-ace-coap-est-00
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Mar 2018 08:08:10 -0000

Hi Jim,

thanks for the comments. See my reactions below.
Jim Schaad schreef op 2018-03-10 22:15:
> I agree with Hannes, this version of the document is much cleaner and 
> much
> clearer.  I think that it has solved most of the problems that I 
> initially
> had with the draft.  It is not ready to progress as there are still 
> sections
> that are marked as TODO.  But it is much closer to finishing that it 
> was.

That sounds hopeful. Agree about the TODOs
> I still have a couple of comments from a quick read through of the 
> document.
> In section 2 - There will be a problem in that the port format 
> extension is
> being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 
> 1.3
> section for clarity.

You mean for backward compatibility?

> In section 3- Should we be looking at the use of COSE rather than CMS 
> for
> encryption of key services?

That is a question that needs some discussion by others.
In the recent draft-richardson-anima-ace-constrained-voucher-03, we 
encrypt the CBOR serialized voucher with either CMS or COSE, as signaled 
in the content format.
Also there is a new draft draft-selander-ace-coap-est-oscore-00 that 
discusses the use of OSCORE for est over coap
Introduction of COSE in est-coaps draft may need alignment with the 
other drafts.

You suggest to use COSE for server key generation only to better protect 
the keys, and all other services to be encrypted with CMS?

> *  Do you have the option to additionally support the long name for the
> service as well as the short name?  MUST have short name MAY have long 
> name?

Agree, should work that out in more detail.
> *  In section 6- All proxies are required by CoAP blocking to 
> re-assemble
> the entire message at the proxy.  It can re-block things going to the 
> next
> proxy.  While there is no requirement that the proxy get the entire 
> message
> before sending on pieces, this should be common practice and would be
> required for a CoAP/HTTP proxy.

Agree fully, we need to clarify that.
> * Should probably add a note in section 6 that any proxy that 
> terminates the
> DTLS connection is going to be required to act as an RA.  RAs are 
> required
> to have the entire request for adding authentication as necessary.

This is visible in the figure of section 6, but needs elaboration in the 
> Jim

Many thanks, this helps to get our text more concrete and complete.

> _______________________________________________
> Ace mailing list