Re: Genart last call review of draft-campbell-sip-messaging-smime-03

[Ben Campbell <[e-mail]>]

Hi Peter, thanks for your review. Please see inline:

Ben.

> On Oct 8, 2018, at 9:57 PM, Peter Yee <[e-mail]> 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".
>