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

Daniel Migault <> Wed, 03 March 2021 04:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E87833A1882 for <>; Tue, 2 Mar 2021 20:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rjQSnN7EA9_F for <>; Tue, 2 Mar 2021 20:09:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56E3C3A187E for <>; Tue, 2 Mar 2021 20:09:23 -0800 (PST)
Received: by with SMTP id f145so4946855vka.8 for <>; Tue, 02 Mar 2021 20:09:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0GvBlqvx812T4LWddsyM5qlpZsqaPtME7c5+VpOPBR4=; b=qr8YDNVHGxmDJMpEjWjKfl2W7xMnL8qM02AJiQmHibeQBUBN1fNPq5VOLg+nOX18OM HJ+vYfbPasAQggfELt0dTum1H5WC3bMHAn9GNrOP3anMvaLibGxYkUzaIN66dkqWam0x KdB6n10Py0b6WzAZ50Z0zKMfISMnhBOxPeghbNsSCyE0BeYzE13Hiinr7CDqCy9SnRGI t5VBpYf74/OWRTamhwOEL+XBNUKzL0EWb7hCFAaeOWVIhNrjE5wlBcGUQQxRc00ehekv I2JThCNjotsRPuR/xtmakXXU6FpoPS8W01INd3L4j8sM1Zlcpjhy7krAVJzAL3XcPUnj KL4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0GvBlqvx812T4LWddsyM5qlpZsqaPtME7c5+VpOPBR4=; b=l0cVKtmeIuveL9BEFrJeusmnS48a8/x7/NQFQpCVpZ+z1CMI/97FusvC59LJPBJI0o oEWi3z3pFGxmtOCINzCiiFMHpvdOApLNbjNoZrEqvkPr7kCWI7kZog/lk2eUQ18YPOq9 QzR6Lve+Rl90AQWBHfDA2jN2V6wSc61sfQwjxUVeZHq7giR/FGTmE2kNocrISKGelW7g 4V5vTT7Qm4pZiUxKc2FrLGzWNQluHpX3Phg+jUlRrevLC/58M65rhK0EAn6j0nNgMDT4 FdY6R/1l9BJVRjJVgIpvWojBjiNT6hy9sZjfgeXPistRWJleEza1KcM6wfHIyjCrgmmm 9wPw==
X-Gm-Message-State: AOAM531ZX0iFUDz8cu2svWrBZ96ZpSGGq/YHdVaD5Fo17iLOvuL9c0zJ EEYjz04R9P1+8Ey6Rgm06ZZBxWYJPDevflHFdwY=
X-Google-Smtp-Source: ABdhPJzkrfzhxhDh8Zzeo3CqPk5TWwZ9McJ80PrwxlA9zeOTic9XEgsdM0OgdBKCB2YIpO5OeNYdosGsbHgCa/A9p4Y=
X-Received: by 2002:a1f:9ed8:: with SMTP id h207mr14388493vke.13.1614744561591; Tue, 02 Mar 2021 20:09:21 -0800 (PST)
MIME-Version: 1.0
References: <871rdqihww.fsf@wangari> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <87v9a94m60.fsf@wangari>
In-Reply-To: <87v9a94m60.fsf@wangari>
From: Daniel Migault <>
Date: Tue, 2 Mar 2021 23:09:10 -0500
Message-ID: <>
To: Olaf Bergmann <>
Cc: =?UTF-8?Q?G=C3=B6ran_Selander?= <>, Russ Mundy <>, "" <>, Stefanie Gerdes <>, Francesca Palombini <>, Daniel Migault <>
Content-Type: multipart/alternative; boundary="000000000000ff2b6505bc9a035b"
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: Wed, 03 Mar 2021 04:09:26 -0000

Thanks for the feedbacks Olaf. So I understand why we need such flexibility
on the client side. The main reason seems that the communication with the
AS is seen as bootstrapping the communication between the client and the RS
and as such we would like to keep them as independent as possible.

I see interoperability being achieved when a) client, RS, and AS
implemented by independent vendors and b) all three follow the framework
and the given profile is sufficient to make them work together. Currently
the client - RS communication is well defined, but the client AS
communication is left to a RECOMMENDATION.

RFC2119 defines RECOMMEND as follows:

SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

The question becomes how RECOMMENDED is sufficient or not.

It seems to me the definition above makes it clear that
the recommended protocol is expected to be supported, and AS or clients
that are independently developed are expected to support the recommended
protocol. To ensure the implementers are well aware of the consequences of
the implication we could clarify this explicitly. Of course this does not
provide a formal proof for interoperability, but this seems acceptable in
the scope of a framework.

>From the latest suggestion, I would propose the following changes, - that I
expect will reach consensus. Please let us know by Friday  March 5 if you
agree or disagree with the proposed changes.

 Section 5:
"Profiles MUST specify a communication security protocol that provides the
features required above."

"Profiles MUST specify a communication security protocol between client and
RS that provides the features required above. Profiles MUST  specify a
communication security protocol RECOMMENDED to be used between client and
AS that provides the features required above. Profiles MUST  specify for
introspection a communication security protocol RECOMMENDED to be used
between RS and AS that provides the features required above. Such
recommendations are expected, among others, to guarantee independent
implementations interoperate."

Section 6.2:
  "Profiles MUST specify how communication security according
   to the requirements in Section 5 is provided."
"The requirements for communication security of profiles are specified
in Section 5."


On Tue, Mar 2, 2021 at 10:20 AM Olaf Bergmann <> wrote:

> 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.
> Grüße
> Olaf

Daniel Migault