Re: [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

[Benjamin Kaduk <[e-mail]>]

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