Hello Marco, Thank you for the review. My responses are inline. Kind regards, --Cigdem
> > > > [General] > > * Refer the AIF adopted draft rather than the individual submission. > > * Some references are included twice side by side, e.g. RFC 4949 and RFC > 7800. > > [Section 1] > > * Add an inline reference to RFC 8446 for TLS 1.3. I think it's good > adding also references to CoAP and CBOR(-bis). > > > [CS: Added to https://github.com/ace-wg/mqtt-tls-profile/issues/65 <https://github.com/ace-wg/mqtt-tls-profile/issues/65>, will be fixed in the next submission] > [Section 2.2.1] > > * In the paragraph on "TLS:Known(RPK/PSK)-MQTT:none", the last two > sentences can clarify that they apply to TLS 1.2. As to the analogous > alternative provision of the token in PSK mode for TLS 1.3, that can point > to "identity" in the "identities" entry of "Pre-Shared Key" ClientHello > Extension. > > [CS: I think it is better to change the wording to match what is defined for TLS 1.3, as it is the recommended version. Created new issues at https://github.com/ace-wg/mqtt-tls-profile/issues/69 Will fix. ] > > [Section 2.2.4.1] > > * Section 2.2.4 said that the two-byte integer length indicates the amount > of following bytes within Authentication Data. However this section refers > to the two-byte length as only the token length, i.e. it does not seem to > cover also the MAC/Signature (whose length might be assumed from the used > algorithm), even though that's still part of Authentication Data. Could you > please confirm or clarify? > [CS: This is because the Authentication Data explained under 2.2.4 is binary data. The binary data in MQTT is represented by a two-byte integer length, which indicates the number of data bytes, followed by that number of bytes. So, we have the total length of the entire Authentication Data, Token length + token + (total length - token length) of MAC data. I hope this is more clear. Do you think I should repeat what binary data is at the subsections rather than explaining in 2.2.4? ] > * It's worth making it explicit that the PoP key is used to compute the > MAC or the client signature. > > * s/and, the server/and the server > > * Remove the final closed parenthesis. > [CS: Added to https://github.com/ace-wg/mqtt-tls-profile/issues/65 <https://github.com/ace-wg/mqtt-tls-profile/issues/65>, will be fixed in the next submission] > [Section 2.2.4.2] > > * Shouldn't the Authentication Data in the AUTH message from the server > start with a 2-byte server nonce length? > [CS: the client is calculating a MAC over its nonce and server nonce and sending it back, with the information of its nonce. I assumed the RS would remember its nonce length] > > * Like for the AUTH message from the client, see the comment above for > Section 2.2.4.1 about what the 2-byte length covers (i.e., here too I would > have expected it to cover also the MAC/signature, not just the nonce). > [CS: Has my previous explanation clarified this? client_nonce length + nonce (the size of AUTH DATA - client_nonce_length) of MAC of (client_nonce+server nonce) > * Like for the comment above for Section 2.2.4.1, it's worth making it > explicit that the PoP key is used to compute the MAC or the client > signature. > > > [Section 2.2.5] > > * s/RS MUST verify/the RS MUST verify > > * Please, add references for HS256 and Ed25519. > > > [Section 3] > > * s/to all topic3/to all 'topic3' > > [Section 6.1] > > * s/as a UTF-8/is a UTF-8 > [CS: Added to https://github.com/ace-wg/mqtt-tls-profile/issues/65 <https://github.com/ace-wg/mqtt-tls-profile/issues/65>, will be fixed in the next submission] > > ================================ > > > On 2020-09-01 22:54, Daniel Migault wrote: > > Hi, > > This email starts a 2 weeks Working Group Last Call for > draft-ietf-ace-mqtt-tls-profile. Please review the document available > here [1] and provide your feed backs by September 15 2020. > > Yours, > Jim and Daniel > > [1] https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ > > > -- > Daniel Migault > Ericsson > > _______________________________________________ > Ace mailing [email protected]https://www.ietf.org/mailman/listinfo/ace > > > -- > Marco Tiloca > Ph.D., Senior Researcher > > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistagången 16 > SE-164 40 Kista (Sweden) > > Phone: +46 (0)70 60 46 501https://www.ri.se > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
