Hi Marco, as you have suggested before, I have now included more test in draft-ietf-ace-extend-dtls-authorize that elaborates on the caveats of session establishment for the extended DTLS profile.
Please see [1] for the new text. (To use keywords from BCP14 and ACE terminology, I also had to add a new section Terminology.) [1] https://github.com/ace-wg/ace-extend-dtls-authorize/pull/1 On 2022-02-18, Marco Tiloca <[email protected]> wrote: >> 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. Grüße Olaf
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
