Hi! Paul and I are load balancing, so I'll be the responsible AD for draft-ietf-ace-extend-dtls-authorize-04 moving forward. I performed an AD review on the document and my feedback is as follows:
** Document Meta-data. s/Updates: draft-ietf-ace-dtls-authorize /Updates: RFC9202/ ** Abstract. The abstract text needs to name the RFC that it is updating per the metadata. OLD This document updates the CoAP-DTLS profile for ACE by specifying that the profile applies to TLS as well as DTLS. NEW This document updates the CoAP-DTLS profile for ACE described in RFC9202 by specifying that the profile applies to TLS as well as DTLS. ** Section 1. Editorial clarity OLD This feature is supported by the OSCORE profile [RFC9203] but is lacking in the DTLS profile. NEW This dual support for TLS and DTLS is already supported by the OSCORE profile [RFC9203]. ** Section 1 The same access rights are valid in case transport layer security is provided by either DTLS or TLS, and the same access token can be used. Could this language please be refined so it is clearer on who the target is? Is guidance to the RS (that given a token, it should read anything into whether it was presented over DTLS or TLS)? ** Section 3. the Client MAY try to connect to the Resource Server via TLS, or try TLS and DTLS in parallel to accelerate the session setup. What happens if the RS responds to a connection on both protocols? ** Section 3. This error SHOULD be handled by the Client in the same way as unsupported ACE profiles. Can this be explained a bit more. The client has a token with "coap_dtls" but the connection failed. How would it distinguish between the peer being misconfigured (and not responding) vs. not supporting this protocol? What is the alternative way to handle it (given that this is SHOULD as opposed to a MUST)? ** Section 3. If the Client is modified accordingly or it learns that the Resource Server has been, the Client may try to connect to the Resource Server using the transport layer security mechanism that was previously not mutually supported. Does this imply some kind of state is kept? If so, how is that managed? ** Section 3. If this message exchange succeeds, the Client SHOULD first use the same underlying transport protocol for the establishment of the security association as well Is this the same things as roughly saying that the Client SHOULD connect to the AS for the token request over the same protocol it successfully contacted the RS? Recommend explicitly mentioning the AS here. ** Section 3. Clients that support either DTLS or TLS but not both SHOULD use the transport protocol underlying the supported transport layer security mechanism also for an initial unauthorized resource request. I'm not following something here. If the Client only supports one of the protocols, what's the optionality suggested by the SHOULD in using it. Either it tries to uses the single protocol it supports, or no connection can be made. ** Section 4. Please Use the exact registry field names: OLD The following updates have been done for the "ACE Profiles" registry for the profile with Profile ID 1 and Profile name coap_dtls: NEW The following updates have been done to the "ACE Profiles" registry for the profile with a "CBOR Value" field value of 1 and "Name" of "coap_dtls": ** Section 4. Is the WG sure it doesn't want two references, [RFC9202] and this [RFC-XXXX] ** Section 5. Should draft-ietf-uta-rfc7525bis apply here instead of RFC7525? ** Section 5. Don't the security considerations of RFC9202 also still apply here? Regards, Roman _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
