Subject: [Ace] Last Call: <draft-ietf-ace-mqtt-tls-profile-14.txt> (Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication and Authorization for Constrained Environments (ACE) Framework) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 17 Feb 2022 15:07:40 -0800

The IESG has received a request from the Authentication and Authorization for
Constrained Environments WG (ace) to consider the following document: -
'Message Queuing Telemetry Transport (MQTT)-TLS profile of
   Authentication and Authorization for Constrained Environments (ACE)
   Framework'
  <draft-ietf-ace-mqtt-tls-profile-14.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2022-03-03. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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/

No IPR declarations have been submitted directly on this I-D.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 17 Feb 2022 15:11:31 -0800

I started the last call so as to make the cutoff for the March 10th IESG
telechat, but noticed a few things in the diff that can be tightened up.
I will try to send a PR before directorate reviews start trickling in...

Thanks for getting the new version up quickly!

-Ben

---

From: Cigdem Sengul <[email-masked]>
Date: Sun, 20 Feb 2022 23:29:39 +0000

Thank you, Ben.
Kind regards,
--Cigdem

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 22 Feb 2022 12:06:16 -0800

> 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