Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

Olaf Bergmann <> Tue, 02 March 2021 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30DE33A1CCC for <>; Tue, 2 Mar 2021 07:21:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IG7XKB_Uv0uw for <>; Tue, 2 Mar 2021 07:21:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AEB1D3A2941 for <>; Tue, 2 Mar 2021 07:20:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4Dqgn3703hz107Y; Tue, 2 Mar 2021 16:20:39 +0100 (CET)
From: Olaf Bergmann <>
To: Daniel Migault <>
Cc: =?utf-8?Q?G=C3=B6ran?= Selander <>, Olaf Bergmann <>, Russ Mundy <>, "" <>, Stefanie Gerdes <>, Francesca Palombini <>, Daniel Migault <>
References: <871rdqihww.fsf@wangari> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 02 Mar 2021 16:20:39 +0100
In-Reply-To: <> (Daniel Migault's message of "Tue, 2 Mar 2021 09:27:02 -0500")
Message-ID: <87v9a94m60.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] secdir review of draft-ietf-ace-dtls-authorize-14
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: Tue, 02 Mar 2021 15:21:14 -0000

Hi Daniel,

On 2021-03-02, Daniel Migault <> wrote:

> This is just a follow-up. I would like to be able to close this issue
> by the end of the week, and so far I have not heard any issues for
> profile mandating a protocol. On the other hand, not mandating a
> specific protocol comes with interoperability issues. So unless more
> feed back is provided, I am currently leaning toward ensuring
> interoperability.
> It  would be good for me to hear from the WG and understand what concrete deployment
> issues the two statements below would raise:
>     * OSCORE profile mandating the AS to support OSCORE and have the C <-> AS using
>     * DTLS profile mandating the AS to support DTLS and have the C <-> AS using DTLS. 

I think the major issue is that a client that implements both OSCORE and
DTLS cannot just switch from one mechanism to the other because it must
stick to either one or the other. This also raises the question what
happens if an AS is contacted by the client via OSCORE but the RS only
supports DTLS: Is the client allowed to switch from OSCORE to DTLS if
the AS says so?

Another aspect is that we would need to add another specification if a
client implementing the DTLS profile wants to contact the AS via TLS. As
CoAP over TLS is well-defined, this would not make any difference
regarding the security or the handling in the application, but mandating
DTLS in the profile would currently preclude the use of TLS.