[Ace] second AD evaluation of draft-ietf-ace-mqtt-tls-profile-13

[Benjamin Kaduk <[e-mail]>]

Hi all,

As promised, here are my comments on the -13.


I put some text to this effect in my pull request
(https://github.com/ace-wg/mqtt-tls-profile/pull/96), but technically
RFC 7250 allows independent negotiation of the client using a RPK and
the server using a RPK, but our text is written as if it's
all-or-nothing.  We can probably just make that an assumption of how we
work and not have to go into detail about how a mixed mode would work.

Section 1

> Publish requests from the Clients to the Broker and from the Broker to
> the Clients

I'm not entirely sure how much we say about the second half specifically
-- do we need to keep that in?

Section 2.2.3.2

The procedures we list here only make sense for TLS 1.3
If we wanted to support TLS 1.2 with them we'd need to note that a PSK
ciphersuite is needed and how to populate the PSK identity in the
ClientKeyExchange, and reference RFC 4279.  I put some text in my PR
that qualifies this scenario as being TLS 1.3-only on the basis that we
don't need to go to so much effort to support TLS 1.2+PSK.

Section 2.2.4

Figure 7 and its adjacent prose shows the client nonce as variable
length (or at least, explicit length with no mention of being constant),
but Figure 8 shows the client nonce as fixed length (8 bytes).

Section 2.3

We say that the JWT scope value is a single value with internal
structure as a JSON array, but I think we have to interpret that in the
context of RFC 6749's definition of scope as a list of space-delimted
case-sensitive strings.  That is, in the formal grammar, the "scope"
parameter value is a single string, and any internal spaces in it are
delimters between the individual scope values.  So, we need to make our
JWT scope value fit into the expected shape, which in particular means
we need to be encoded as a string with no internal spaces.  However,
MQTT does allow spaces in topic names, so the naive formulation of
encoding the JSON object as a string would artificially limit what
topics we can authorize the use of.  If we stick with using the "scope"
like this, we may find ourselves needing to do some percent- or base64-
encoding of the JSON array to produce a usable scope value...but we
could also consider something more drastic and switch to using the OAuth
"Rich Authorization Requests"
(https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/) that defines a
new "authorization_details" parameter that is like scope but allows a
much richer structure.  My understanding is that, while use of
structured "scope" like we propose is regularly observed in the wild,
OAuth purists really don't like it, since it's not what scope was
intended to be about.

(Also, the example in Figure 10 does include spaces in it.)

Section 5

Apparently I didn't comment on it the first time I read this, but it's
very interesting to say that the Broker "MUST continue publishing the
retained messages **as long as the associated tokens are valid**"
(emphasis mine).  That seems to imply a model where the authorization
check happens at the Broker->consumer leg, in addition to (or instead
of?) at the publisher->Broker leg.  To some extent the right behavior
here depends on what one uses as the definition for "publishing"
something, but this does set us up for a scenario where a retained
message will disappear after some amount of time.  That seems to be a
divergence from stock MQTT, and in some sense also from what we've
specified for Will messages, so if we're going to keep it, I think we
should mention in the security considerations that performing
authorization checks in this way will result in future new subscribers
not receiving a retain message that was valid when originally sent.
If, on the other hand, this "as long as the associated tokens are valid"
refers to the tokens of the subscribers, that would be a less surprising
situation, but still merit some clarification.

Appendix A

It looks like the template doesn't actually have a "Content format" line
in it, so I'm not sure if we need to keep that in here.

Thanks,

Ben