Peter, thanks for your review. Ben, thanks for following up. I have entered a No Objection ballot.
Alissa > On Oct 10, 2018, at 6:11 AM, Ben Campbell <[email protected]> wrote: > > > >> On Oct 9, 2018, at 10:50 PM, Peter Yee <[email protected]> wrote: >> >> Ben, >> >> Regarding the metadata, it would seem to that these intermediaries >> would be inserting this metadata regardless of whether S/MIME was used or >> not. As the intermediaries can't read the S/MIME messages (assuming >> encryption), they aren't revealing anything that the sender could have >> protected more than is done with S/MIME over the message content. If >> there's a case where S/MIME induces the addition of metadata that would not >> be otherwise attached, then I could see a problem. It's just not clear to >> me from the text given that this is the case. > > Hi Peter, > > The issue isn’t that S/MIME enables this; it’s that it doesn’t protect > against it. The sender could go to great effort to encrypt their data so that > only the receiver can read it, and find that the “network” adds it back in > cleartext. > > This can happen whether or not S/MIME encryption is used, but one assumes the > sender uses it with an expectation of privacy. > > Would it help to add something to the effect of “The use of S/MIME > encryption will not prevent privacy leaks introduced by header enrichment.” > to the beginning of the paragraph? > >> >> One more potential nit: Page 22, Section 12, 4th paragraph, 4th >> sentence: verify that you really want UAS (i.e., User Agent Server) in that >> sentence. I'm not familiar enough with the context to know if you didn't >> really mean UAs (User Agents) as was used in the previous sentence. > > You are correct, it should be UAs. Good catch. > > Thanks! > > Ben. > >> >> Thanks for considering my input. >> >> -Peter >> >> -----Original Message----- >> From: Ben Campbell [mailto:[email protected]] >> Sent: Tuesday, October 09, 2018 9:55 AM >> To: Peter Yee >> Cc: [email protected]; [email protected]; >> [email protected] >> Subject: Re: Genart last call review of draft-campbell-sip-messaging-smime-03 >> >> Hi Peter, thanks for your review. Please see inline: >> >> Ben. >> >>> On Oct 8, 2018, at 9:57 PM, Peter Yee <[email protected]> wrote: >>> >>> Reviewer: Peter Yee >>> Review result: Ready with Nits >>> >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed by >>> the IESG for the IETF Chair. Please treat these comments just like >>> any other last call comments. >>> >>> For more information, please see the FAQ at >>> >>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >>> >>> Document: draft-campbell-sip-messaging-smime-03 >>> Reviewer: Peter Yee >>> Review Date: 2018-10-08 >>> IETF LC End Date: 2018-10-10 >>> IESG Telechat date: 2018-10-25 >>> >>> Summary: This draft updates and clarifies the use of S/MIME with SIP >>> and MSRP to provide end-to-end message protection. A few nits should >>> be corrected and there are a couple of requests listed as minor >>> issues, but those can be safely ignored. [Ready with nits] >>> >>> Major issues: None >>> >>> Minor issues: >>> >>> Section 10/Appendix A: It would be good to supply the private keys >>> used for signing and encryption in the example messages so that >>> implementers can test the correctness of their implementations against >>> the RFC. As it stands, the examples mostly serve to show format. >> >> The purpose was in fact to show format. We did not mean these to be test >> vectors, and I don’t think this draft is the right place for that. At best, >> we would be showing the output of a particular version of OpenSSL. >> >>> >>> Page 22, 2nd full paragraph, 2nd sentence: mention is made of >>> information that would have otherwise been encrypted. It's not clear >>> how use of S/MIME is inducing that information to be sent in the clear >>> rather than encrypted. >>> Perhaps a brief explanation would help rather than relying on "certain >>> cases”. >> >> The point is that the the intermediaries insert cleartext metadata that >> includes information that the sending client might have preferred to be >> encrypted. >> >> How about the following: >> >> OLD: >> Certain messaging services, for example those based on CPM and RCS, >> may include intermediaries that attach metadata to user generated >> messages. In certain cases this metadata may reveal information to >> third parties that would have otherwise been encrypted. Implementors >> and operators should consider whether this metadata may create >> privacy leaks. Such an analysis is beyond the scope of this >> document. >> >> NEW: >> Certain messaging services, for example those based on CPM and RCS, >> may include intermediaries that attach metadata to user generated >> messages. In some cases this metadata may include information >> that the sender might have preferred not to send in clear >> text. Operators should consider whether this metadata may create >> privacy leaks. Such an analysis is beyond the scope of this >> document. >> >>> >> >>> Nits/editorial comments: >> >> I will fix the editorial issues, save one on which I have commented below: >> >>> >>> Page 1, header: remove "RFC" in three places in the "Updates" header. >>> (Run idnits nad read through the output. There's more.) >>> >>> Page 3, Section 1, 5th paragraph, last sentence: append a comma after >>> "RFC 3428". >>> >>> Page 4, Section 3, 1st paragraph, 1st sentence: change "SIP based" to >>> "SIP-based". >>> >>> Page 4, Section 3, 4th paragraph, delete an extraneous space before >>> "already". >>> >>> Page 5, 1st paragraph, 1st sentence: change "send" to "sent". >>> >>> Page 5, 2nd paragraph: append "to" after "intended". >>> >>> Page 7, 2nd paragraph after "id-aes128-CBC", 1st sentence: append >>> algorithm after "AES-128-WRAP" *or* change "AES-128-WRAP" to "AES-128 >>> wrap" as given in RFC 3565. >>> >>> Page 7, 3rd paragraph after id-aes128-wrap, 2nd sentence: append "algorithm" >>> after (ECDH). Do something similar for the next two sentences. >>> >>> Page 7, Secion 4.3, 1st sentence: expand UAC here on first use. >>> >>> Page 8, section 4.4.1, 1st paragraph: insert "as" before "a SIP URI". >>> >>> Page 9, 6th paragraph: change "received" to "receive". >>> >>> Page 9, 8th paragraph: change "out of band" to "out-of-band". >>> >>> Page 10, Section 7.3, 1st paragraph, last sentence: insert a double >>> quote before "Unsupported". >>> >>> Page 12, Section 8.3, 3rd paragraph, 2nd to last sentence: change >>> "s/mime" to "S/MIME". >>> >>> Page 13, Section 8.4, 2nd paragraph, 2nd sentence: change "answer" to >>> "answerer". >>> >>> Page 13, Section 8.4, 2nd paragraph, 3rd sentence: delete duplicated "the". >>> >>> Page 13, Section 8.5, 1st paragraph, 2nd sentence: delete duplicated >>> "since". >>> >>> Page 14, 1st full paragraph, last sentence: change "Intant" to "Instant". >>> >>> Page 14, Section 9.2, 1st sentence: append a space after "mechanism". >>> >>> Page 15, Section 10, 1st paragraph, 3rd sentence: join "over" and "running" >>> into a single word. >>> >>> Page 15, Section 10, 2nd paragraph: if you wish to be historically >>> correct, insert "Mr." before "Watson". That would, however, cause a >>> painful exercise in regenerating the examples, so feel free to ignore this >>> suggestion. >> >> We will fix this if we find other reasons to regenerate the example, but >> otherwise we will exercise the option to ignore for the reason you mentioned >> :-) >> >>> >>> Page 15, section 10.1, 1st paragraph, 2nd sentence: change "a" to "an" >>> unless "smime" is not pronounced "ess-mime". >>> >>> Page 22, 1st partial paragraph, last sentence: change "vulnerabile" to >>> "vulnerable". >>> >> >> >> > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
