Re: [Ace] Éric Vyncke's No Objection on draft-ietf-ace-dtls-authorize-16: (with COMMENT)

Olaf Bergmann <> Mon, 10 May 2021 13:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 297683A1C45; Mon, 10 May 2021 06:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GImLzqeLRYaM; Mon, 10 May 2021 06:12:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C77823A1C43; Mon, 10 May 2021 06:12:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4Ff1gX5jcTzyXT; Mon, 10 May 2021 15:12:40 +0200 (CEST)
From: Olaf Bergmann <>
To: =?utf-8?Q?=C3=89ric?= Vyncke via Datatracker <>
Cc: "The IESG" <>, =?utf-8?Q?=C3=89ric?= Vyncke <>,,,
References: <>
Date: Mon, 10 May 2021 15:12:40 +0200
In-Reply-To: <> (=?utf-8?Q?=22=C3=89ric?= Vyncke via Datatracker"'s message of "Tue, 23 Mar 2021 07:05:03 -0700")
Message-ID: <87czty4trr.fsf@wangari>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Ace] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?ace-dtls-authorize-16=3A_=28with_COMMENT=29?=
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, 10 May 2021 13:12:49 -0000

Hi Éric,

sorry for the delayed reply. Please find our comments inline.


On 2021-03-23, Éric Vyncke via Datatracker <> wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-ace-dtls-authorize-16: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you for the work put into this document.
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated), and some nits.
> I hope that this helps to improve the document,
> Regards,
> -éric
> == COMMENTS ==
> Is there any reason to use DTLS 1.2 while the document DTLS 1.3 is on
> the same
> IESG telechat ? I understand that they are from different WG but this
> may not
> be the most efficient to specify a protocol using DTLS.

At some point, the WG has decided to pursue standardization for DTLS 1.2
first and specify the use over DTLS 1.3 later in a separate
document. The reason is that DTLS 1.2 has been widely deployed in
current lightweight DTLS libraries that are available in current IoT
platforms. In general, this specification would also apply to DTLS
1.3. Do you think that we should clarify this in the introduction? For


  In this profile, a client and a resource server use CoAP {{RFC7252}}
  over DTLS version 1.2 {{RFC6347}} to communicate.


  In this profile, a client and a resource server use CoAP {{RFC7252}}
  over DTLS version 1.2 {{RFC6347}} to communicate. This specification
  uses DTLS 1.2 terminology but later versions such as DTLS 1.3 can
  be used instead.

> -- Section 3.1 --
> Has the "resource owner (RO)" been defined earlier ?

The ACE framework uses terminology from OAuth 2.0, including the
resource owner. The DTLS profile uses ACE framework terminology (see
section 2). Does that suffice?

> -- Section 3.2.2 --
> The wrong selection of RPK recovery is unclear to me. What happens if the
> client does not have the right public key ?

The client may try to re-request the access token. If this fails, the
client should re-register with the AS. We added text to section 3.2.2 to
clarify this situation.

> == NITS ==
> Sometimes it is "Raw Public Keys", or "RPK" or "RawPublicKey"... Is it on
> purpose to use 3 different writings for possibly the same concept?

fixed: replaced rawpublickey with Raw Public Key