> On Oct 9, 2018, at 10:50 PM, Peter Yee <peter@xxxxxxxxxx> 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:ben@xxxxxxxxxxx] > Sent: Tuesday, October 09, 2018 9:55 AM > To: Peter Yee > Cc: gen-art@xxxxxxxx; draft-campbell-sip-messaging-smime.all@xxxxxxxx; ietf@xxxxxxxx > 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 <peter@xxxxxxxxxx> 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". >> > > >
Attachment:
signature.asc
Description: Message signed with OpenPGP
