Ben,
Thanks again for the thorough review of the ACE DTLS profile and my
sincere apologies for the long time it took to process. Please find our
comments inline. As this comprises a lot of changes, the proposed text
already has been included in the Editor's copy [1]. Our proposals for
new text are in the section-by-section comments.
[1] https://ace-wg.github.io/ace-dtls-profile/
Benjamin Kaduk writes:
> Hi all,
>
> Some high-level remarks before delving into the section-by-section
> comments:
>
> This document is pretty clearly DTLS 1.2-specific -- it talks about
> particular protocol messages, message fields, and cipher suites that
> simply do not apply to DTLS 1.3. In order to use this profile with DTLS
> 1.3, we'd need to specify the analogous behavior/requirements to these
> (including standalone signature schemes and key-exchange groups, which
> are now both separately negotiated from the cipher suite).
> Given that DTLS 1.3 is past WGLC and only a few documents behind this
> one in my review queue, it seems fairly prudent to spend some time and
> cover how DTLS 1.3 would work here, since otherwise this document will
> become stale shortly after (or even before!) its publication as an RFC.
>
> There's probably some additional discussion to include about the usage of
> key identifiers in this document versus the potential uses described in
> the core framework. Specifically, the framework reminds us that "no
> assumptions should be made that it is unique in the domains of either
> the client or the RS" yet this document is using the kid as input to a
> KDF that produces keys that must be unique across all clients, and
> allowing live/instant authorization updates based on matching "kid".
> How shall we resolve this apparent conflict?
>
> We also are potentially in violation of the framework's requirements
> with respect to the independent selection of profiles for client/AS and
> client/RS interactions -- at present, when DTLS+RPK is used for
> client/RS, we require that DTLS+RPK is also used for client/AS, in order
> to prove possession of the key. We could perhaps weasel our way out by
> saying that the framework's requirement applies at the profile
> granularity, and with symmetric PSK we can be fully independent, but we
> still need to say something about this property and the interaction with
> the framework's requirements.
>
> This profile is mostly applicable to the client/RS communications and
> feels like it only provides some of the picture for use with client/AS
> interactions. (It doesn't really say much of anything about RS/AS
> interactions.) The introductory discussion does not do a great job of
> painting that picture, and I'd like to see it more clearly introduced
> that the bulk of our coverage is for the client/RS interaction. We also
> lean heavily on the existing out-of-band configuration and key material
> shared between client and AS to secure the client/AS communications; we
> could probably tighten up the discussion about exactly what parameters
> of client/AS communication are specified by this profile.
The introduction has been revised according to your suggested text, see
below. We also have included some text on the out-of-band configuration
in a new subsection in the security considerations. The important thing
here really are the client/RS and client/AS interactions. Regarding
client/AS, much of this is out of scope as there are certain
OAuth-related assumptions on how these entities get in touch with each
other; neither the framework nor the profile can do much about it
without creating a new enrollment protocol. Regarding the RS/AS
interaction, there is normative language that describes what each of
these entities needs to do in each protocol step covered by the
document. The necessary out-of-band configuration again is described in
the new subsection in the security considerations as well as some
clarifications in the text, see below.
> We do not say anything about DTLS session resumption (or renegotiation,
> though not talking about that one is perfectly fine); that's a fairly
> core DTLS concept that we should give some guidance on.
Not sure if we really need to but if you think this is necessary, we can
comment on this, of course.
> Looking through Appendix C ("Requirements on Profiles") of the
> framework, do we want to say anything about:
>
> - using the client credentials grant with this profile, as that's IIRC
> the only example we show
Do you think we need to say anything here? The actual grant used to
make the client known to the AS is out of scope for the profile as
long as the requirements given here are met.
> - require that DTLS be used in a mode that provides replay protection
Added as a requirement in Section 2.
> - when the client uses the authz-info endpoint instead of the
> "psk_identity" field to convey the token to the RS, how does the RS
> know which client is connecting (and thus what PSK to use), and what
> does the cli
