On Thu, Feb 17, 2022 at 03:07:40PM -0800, The IESG wrote: > > > Abstract > > > This document specifies a profile for the ACE (Authentication and > Authorization for Constrained Environments) framework to enable > authorization in a Message Queuing Telemetry Transport (MQTT)-based > publish-subscribe messaging system. Proof-of-possession keys, bound > to OAuth2.0 access tokens, are used to authenticate and authorize > MQTT Clients. The protocol relies on TLS for confidentiality and > MQTT server (broker) authentication. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ [n.b. I am responsible AD for this document and requested the IETF Last Call with the intention to make the following comments as last-call comments, rather than waiting for another I-D revision and make it a certainty that I will need to hand the document over to my successor] I posted a pull request with some proposed changes at https://github.com/ace-wg/mqtt-tls-profile/pull/98 . Most of them are just editorial (adding articles/etc.), but a couple are noteworthy enough to mention them here, lest other reviewers rediscover the issues independently: - we (rightly) recommend stronger ciphers than the ACE DTLS profile, but did so inconsistently -- we demoted (from MUST to MAY) the PSK CCM_8 cipher suite but not the RPK CCM_8 cipher suite, and made the new/stronger MTI just an RPK cipher suite with no MTI PSK cipher suite. My proposal in the PR is to use the ECDSA and PSK versions of the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite from RFC 7525 that the current (-14) version of this draft lists, since the ACE DTLS profile lists ECDSA and RSA variants of the CCM_8 cipher as MTI and thus ECDSA and RSA are "most analogous" to it. But if there's desire to use RSA rather than ECDSA as MTI, that would also be fine -- I'd rather have just one RPK MTI option than have ECDSA there. - The IESG is now preferring to see that any BCP 14 SHOULD directives are accompanied by some discussion of the motivation for the SHOULD or what the exception cases might be; we have SHOULD-level guidance to use the TLS ALPN and SNI extensions, so I added some text to try to motivate the SHOULD: "so the TLS handshake authenticates as much of the protocol context as possible." Thanks, Ben -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
