Marco, Thanks. I have removed the reference to DTLS1.3 and will propose text to address the interoperability issues asap.
Grüße Olaf On 2022-02-18, Marco Tiloca <marco.tiloca=40ri...@dmarc.ietf.org> wrote: > Please, see my replies inline (trimming the solved points) > > > On 2022-02-18 13:42, Olaf Bergmann wrote: >> Hi Marco, >> >> thanks for the thorough review. I have done most of the suggested >> updates (see Editor's copy [1]). >> >> Just a few comments and questions inline. >> >> [1] >> https://ace-wg.github.io/ace-extend-dtls-authorize/draft-ietf-ace-extend-dtls-authorize.html >> >> On 2022-02-18, Marco Tiloca <marco.tiloca=40ri...@dmarc.ietf.org> >> wrote: >> >>> [Section 1] >>> >>> * For consistency with draft-ietf-ace-dtls-authorize , I think >>> here it would be better to refer to RFC 6347 when mentioning >>> DTLS. The original profile only mentions DTLS 1.3 as a possible >>> later version, without pointing to the specification. >> Done. >> >> DTLS1.3 now is not referenced anymore. Do you think a normative >> dependency for DTLS1.3 is required? > > ==>MT > I think you can remove the DTLS 1.3 entry from the list of normative > references. That reference is not present among those in > draft-ietf-ace-dtls-authorize either (where DTLS 1.3 is at least named > once), so it feels even more unnecessary here. > <== >>> * "The same access rights are valid in case transport layer >>> security is either DTLS or TLS, and the same access token can be >>> used." >>> >>> This implies that the "ace_profile" claim in the access token >>> and the corresponding "ace_profile" parameter in the AS-to-Client >>> response still indicate the profile name "coap_dtls", even though >>> TLS might be used between C and RS. I think it's better to >>> highlight it. >> Yes, good point. >> >> I have added the following sentence at the end: >> >> Therefore, the value `coap_dtls` in the `ace_profile` parameter of >> an AS-to-Client response or in the `ace_profile` claim of an >> access token indicates that either DTLS or TLS can be used for >> transport layer security. > > ==>MT > Looks good. > <== > >>> * Building on the previous point, there's probably something more >>> worth clarifying. Let's say that the client receives an >>> AS-to-Client response specifying "ace_profile" with value >>> "coap_dtls". Presumably, the following applies: >>> - The client can feel free to go ahead with TLS or DTLS as >>> it >>> sees fit, if it does not know in advance which the RS prefers or >>> exclusively supports. >>> - Then, if the RS does not show support for DTLS (TLS), the >>> client may want to try again with TLS (DTLS) if supporting it. >>> On the other hand, a client or RS that has been registered >>> to >>> the AS as supporting the "coap_dtls" profile is supposed to >>> support at least one among TLS or DTLS. >> You are raising an interesting point. It might happen that the >> client supports either DTLS or TLS, and the resource server has only >> support for the other transport layer security, they might not be >> able to talk to each other at all. The same might happen for other >> values of 'ace_profile' but for different profiles, the >> AS-to-clientn response would make this transparent. >> >> Do you feel that we should elaborate on the case where ace_profile: >> coap_dtls is returned in the AS-to-Client response but client and >> resource server still will not be able to setup a (D)TLS connection? > > ==>MT > Yes, it would help to elaborate on that. As you say, there is a > possibility of no commonly supported transport security protocol, > although within the commonly supported profile. > > In that case, and assuming that neither of the two parties can be > (promptly) updated to broaden its support, the client would just have > to give up after failing to establish a channel with the only > transport security protocol it supports. > > > Thanks, > /Marco > <== > >> Done >> >> Grüße
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
