[Ace] FW: WGLC comments draft-ietf-ace-coap-est-07

Jim Schaad <ietf@augustcellars.com> Mon, 14 January 2019 19:16 UTC

Return-Path: <ietf@augustcellars.com>
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 11766131226 for <ace@ietfa.amsl.com>; Mon, 14 Jan 2019 11:16:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 ghZqLffFrfpW for <ace@ietfa.amsl.com>; Mon, 14 Jan 2019 11:16:44 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1163913121F for <ace@ietf.org>; Mon, 14 Jan 2019 11:16:44 -0800 (PST)
Received: from Jude (73.96.115.1) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 14 Jan 2019 11:16:37 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: ace@ietf.org
References:
In-Reply-To:
Date: Mon, 14 Jan 2019 11:16:32 -0800
Message-ID: <011501d4ac3d$ab2b9650$0182c2f0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AdSrtk3M3NcfgQ45QNualt2l/rHBKAAh1EAw
X-Originating-IP: [73.96.115.1]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/xWGOZa2haWFzPNiAzTNeaTgeKRE>
Subject: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 14 Jan 2019 19:16:46 -0000

I forgot to include the working group on the to list.

-----Original Message-----
From: Jim Schaad <ietf@augustcellars.com> 
Sent: Sunday, January 13, 2019 9:51 PM
To: 'draft-ietf-ace-coap-est@ietf.org' <draft-ietf-ace-coap-est@ietf.org>
Subject: WGLC comments draft-ietf-ace-coap-est-07


Section 5.7  -  Validate that CBOR array is the correct response type not
multipart/cbor

Section 6 - Based on earlier mails on the list I expected to see a short
description of the purpose of "ArbitraryLabel".  

Section 6 - The fact that there are multiple ways to get the things and they
might not be in the same location.  Some guidance for an application on how
to decide which method should be used and the choice of an ArbitraryLabel to
use would be very helpful.  At present I would guess that I would send a
request to the well known address, if that does not work then do a discovery
but it might be easier to just do the discovery to begin with and not worry
about the well-known address.  That is one would only do discovery if one
was hitting up a resource directory and not the actual machine.  On the
other hand if things are rooted at /est rather than in well-known it would
lead to shorter requests which once one starts doing block wise would be
good.

Section 7 - I would like to see some discussion of using a tls-exporter
rather than tls-unique for this protocol.  I am not sure what the required
changes would be.  I have seen notes that tls-unique is broken for TLS 1.2.

Section 7 - I think it makes sense to say that after a successful enrollment
the (D)TLS link MUST be torn down and the new certificate used to do
authentication in the future.

Section 11.1 - When changing from the implicit trust anchor to explicit
trust anchors, do you expect that the est server that you are going to be
talking to is generally going to change?  I think that it should probably be
recommended that the DTLS connection NOT be persistent across a change in
the trust anchors if they are different.

Nits:

Section 2 para 1:  I would suggest that the last sentence should read along
the lines of "EST is defined to transport messages over HTTPS."

Section 3 para 2:  The phrase 'taken over from' is a bit odd sounding
English.  They could be 'taken from' or 'imported from'.  'taken over' tends
to indicate that you are changing them in some way.  (example use - he took
over the country).

Section 5.5 - SAN needs to be expanded on first use.

Section 6 - Please verify that quotes on the content type when multiple
values are presented are not needed.

Section 8 - This sentence "The EST server can exist outside the constrained
network that supports TLS/HTTP." Does not say what I think you meant to say.
It is unclear if the constrained network is what supports TLS/HTTP.

Section 10.1 - s/registered temporarily/registered provisionally/

s/looke/look/


Examples:

* Section A.1  I don't know what the meaning of Max-Age would be for a GET
request.  You may want to remove this just to avoid confusion.

* Section A.2 - I am unclear about the Content-Format note in this example.
If you are asking for a specific content then the correct option would be
Accept.  If you are indicating the content type of the response then you
should probably put a header line in to that effect.

Jim