From: Cigdem Sengul <cigdem.sen...@gmail.com> Sent: Sunday, March 8, 2020 3:30 PM To: Jim Schaad <i...@augustcellars.com> Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg <ace@ietf.org> Subject: Re: Comments on the MQTT draft Hello Jim, Comments inline. On Sun, Mar 8, 2020 at 7:04 PM Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> > 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). [JLS] I approve of having a recommended method, that is one which everybody will implemented, I just want to ensure people think this is the right one. 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? [JLS] What cryptographic algorithm is used to implement the hash/signature for the two authentication methods – it can be the same for both. 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. [JLS] All of that makes a great deal of sense to me. What if a session expires when a token expires independent of the client’s request for a long session expiry interval. After all, if the token is the identity then if the token expires you can no longer prove you are the same person and thus can have the same session back. You probably need some weasel text about allowing for an expired session to get a new token if it is kept open perhaps, but I have not looked exactly when a connection would be forced closed due to token expiration yet. 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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
