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

Jim Schaad <> Mon, 28 January 2019 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C481131223 for <>; Mon, 28 Jan 2019 13:37:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ozkkmhx6TFCD for <>; Mon, 28 Jan 2019 13:37:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F4E8131246 for <>; Mon, 28 Jan 2019 13:37:09 -0800 (PST)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 28 Jan 2019 13:37:03 -0800
From: Jim Schaad <>
To: "'Panos Kampanakis (pkampana)'" <>, <>
References: <011501d4ac3d$ab2b9650$0182c2f0$> <>
In-Reply-To: <>
Date: Mon, 28 Jan 2019 13:36:58 -0800
Message-ID: <015e01d4b751$9b0d2170$d1276450$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQF61PvzwzMWmD5ENcCTB9smhJ8GWwKQrXUGpmNcLHA=
Content-Language: en-us
X-Originating-IP: []
Archived-At: <>
Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
X-Mailman-Version: 2.1.29
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, 28 Jan 2019 21:37:18 -0000

Clipping out things which are not issues:

> -----Original Message-----
> From: Ace <> On Behalf Of Panos Kampanakis
> (pkampana)
> Sent: Friday, January 18, 2019 12:59 PM
> To: Jim Schaad <>om>;
> Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
> Hi Jim,
> Again, thank you for your thorough reviews. We addressed all of them. The
> new version of the draft is at
> coaps/blob/master/draft-ietf-ace-coap-est.txt
> For a more easily consumable content, your latest feedback was tracked and
> addressed here
> coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+draft-ietf-ace-coap-est-07
> I also lay out the changes  below:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> - About the persistent DTLS connections (Sect 7), the last two paragraphs
> section 7 explain why in some cases DTLS connections need to stay open for
> a limited amount of time. They also point to the Section 11.1 about the
> caveats of a persistent connection and the implicit DB. I do not think it
is up to
> this draft to tell the client that he should use the new cert after an
> enrollment. The old cert might still be perfectly valid or the new cert
may be
> generated for a non DTLS client auth use. So, I don't think we need to
state in
> this draft that the new cert needs to be used in new DTLS connections.
> - About the DTLS connections (Sec 11.1), We have usecases where a client
> does not want to spend the resources, time, performance implications to do
> 3-5 DTLS connections back to back in order to update its trustanchor and
> its enrollments for multiple certs. In this cases, explained in section 7
> paragraphs will keep a persistent DTLS connection. That is what section
11.1 is
> trying to explain. Please keep in mind that in there we state that it is
> RECOMMENDED for the client to start using the new explicit DB right after
> the cacerts request. We just add the MAY keep the authenticated with
> implicit DB DTLS connection open in some cases, but then he MUST use the
> new DB starting for the next DTLS connection.
> So, I think our language in Sections 7 and 11.1 suffices when talking
> persistent TLS connections.

Any time that the set of trust anchors is changed, you have also changed the
set of things that you are going to trust.  If you remove the trust anchor
for the current connection, or restrict it in some manner, you may no longer
have any trust in that connection.  This is the worry that I have.  I
completely agree that doing multiple certificate requests (not sure why) or
a query about the csr attributes followed by the certificate request is
totally reasonable.  

You say that the client should use the new explicit trust anchors right
after the cacerts request, but if you do not tear down the DTLS connection
you are not doing that.  You are still using the old implicit trust anchors.
The MAY in section 11.1 for me is overridden by the previous SHOULD unless
this case is specifically called out in section 7.  I cannot understand the
logic that says when you get a certificate a year from now the explicit TAs
SHOULD be used, but it does not matter when you get the first certificate.

*  It does not look from the version on github that you made any changes for
the 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.

In the virtual CoAP WG meeting last week we went through in some explicit
detail that both Content-Format and Max-Age have no meaning when appearing
on a request and therefore should not be there.