From: Cigdem Sengul <cigdem.sen...@gmail.com> Sent: Tuesday, January 14, 2020 8:25 AM To: Jim Schaad <i...@augustcellars.com> Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg <ace@ietf.org> Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03 Thank you for this review, Jim. Responses inline. On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> > wrote: 2.2.2 - I am unclear under what circumstances you could end put with a token which does not parse when processing a PUBLISH message. If the token cannot be parsed at connection time, that I can understand. However having parsed the token then it does not make sense that the token becomes not parsable at the time of publishing. Am I missing something? [CS] There is a misunderstanding. The PUBLISH message refers to the actual PUBLISH message to the "authz-info" topic which contains the token i.e., this may not parse to a token. (The PUBLISH message is not for other messages that are permissioned in the token.) The client connects (without much security), publishes the token to the public "authz-info" topic, which only the broker can read. Then, disconnects, and tries to connect with ace security. Since MQTT v5 can return error messages in response to PUBLISH messages, here, this is used to signal to the publisher that there is something wrong with its token. Added: https://github.com/ace-wg/mqtt-tls-profile/issues/38 [JLS] Ok – I see where I got mixed in in reading this. I think this may just be a problem on my end and you might not be able to do this better. 2.2.4 - I am having a problem with trying to parse the content of the AUTH property. I have no problems with 2.2.4.3 because this is a zero length sequence of bytes. However for 2.2.4.1 and 2.2.4.2 there is a token (possibly binary with no length prefix) followed by an optional binary cryptographic value. For introspection, I would need to figure out the length of the token before I could make a guess at the length of the cryptographic value. However given that there is no divider this does not seem possible. This may also become a problem for the response from the client in the event that there is a change from an 8-byte nonce to a variable length one. [CS] Not specified a format, because I thought we discarded the idea of using the variable-length nonce based on the meeting in Singapore. What would you suggest - introduce a specific format to accommodate variable length? length_of_token+binary data for token+(the rest is cryptographic value)? https://github.com/ace-wg/mqtt-tls-profile/issues/40 [JLS] I put in a comment on the github issue about what I was looking for. Additionally, my only possible problem with the fixed size nonce is that the IESG or Security Directorate down the line may decide that it is too small for some reason (16 bytes signed by a 521-bit (65+ byte key)). Some might consider it to be small for a SHA-256 MAC operation. Not the exact same situation here for TLS as it is not really a compact protocol. But it may considered to be for the IoT variants being used. I don’t know. Jim I am going to play with something else. I am sure I will find other issues at a different time. Thank you for your review. Much appreciated. --Cigdem Jim Nits: Section 2 Para 1 s/Broker.Figure 1/Broker. Figure 1/ Section 2 Para 1 s/setup.The/setup. The/ Section 2.2.2 Last Para s/when the AS/when the RS/ _______________________________________________ Ace mailing list Ace@ietf.org <mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
