Hello Jim, Comments inline.
On Sun, Mar 8, 2020 at 7:04 PM Jim Schaad <[email protected]> wrote: > 1. I want to verify that the following is the desired statement: There is > a strong preference that TLS not use PSK for authentication. This follows > from the recommendation to use TLS:Anon-MQTT:ace for the authentication > option. I have no problems with this statement, I just want to be sure > that > the group as a whole is ok with this position. I found that I implemented > the SHOULD NOT option for PSK to start with, but that is because I was > trying to be completist not because I think the position is wrong. > To tell the truth, I've put the RECOMMENDED as I believed it was expected that I provide a recommendation. Otherwise, any of the methods are OK (with some exceptions for anon:anon, and over authenticating/authorising with the last mode). > > 2. While implementing I found that there did not appear to be a mandatory > to implement validation algorithm, one needs to be specified. > Do you mean mandatory-to-implement certificate validation policy? > > 3. After reading the log of bugs which have been showing up on the MQTT > code base that I have been using, I think there needs to be text put into > the document to deal with the clean session requirement that this profile > is > enforcing. I am seeing a lot of people who are relying on the fact they > are > not reconnecting with clean session to get QoS information back from the > server in the event of unexpected disconnects. > Yes, I can see this can be problematic but this was to avoid the broker keeping state for clients that are no more authorised to receive those messages. The session state can include actual messages if QoS>=1, so maybe high overhead. Session State in the Server consists of: · The existence of a Session, even if the rest of the Session State is empty. · The Clients subscriptions, including any Subscription Identifiers. · QoS 1 and QoS 2 messages which have been sent to the Client, but have not been completely acknowledged. · QoS 1 and QoS 2 messages pending transmission to the Client and OPTIONALLY QoS 0 messages pending transmission to the Client. The Session Expiry is also set by the client: When a client connects with a long Session Expiry Interval, it is requesting that the Server maintain its MQTT session state after it disconnects for an extended period. Clients should only connect with a long Session Expiry Interval if they intend to reconnect to the Server at some later point in time. When a client has determined that it has no further use for the Session it should disconnect with a Session Expiry Interval set to 0. > > 4. I keep going back and forth on a recommendation that we channel bind in > the challenge response case. I don't have the knowledge to be able to do a > formal proof, but I think that all of necessary conditions are going to be > met without it. However, having the binding included would most likely > make > the proofs that much easier. > Jim > > >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
