Subject: [Gen-art] Genart last call review of draft-campbell-sip-messaging-smime-03

From: Peter Yee <[email-masked]>
Date: Mon, 08 Oct 2018 19:57:05 -0700

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.

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".

Nits/editorial comments:

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.

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".

---

From: Ben Campbell <[email-masked]>
Date: Tue, 9 Oct 2018 11:55:25 -0500

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

Ben.

> On Oct 8, 2018, at 9:57 PM, Peter Yee <[email-masked]> wrote:
> 
> Reviewer: Peter Yee

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.

> 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.

> 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 :-)

---

From: "Peter Yee" <[email-masked]>
Date: Tue, 9 Oct 2018 20:50:41 -0700

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.

	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.

	Thanks for considering my input.

		-Peter

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2018 9:55 AM
To: Peter Yee
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Genart last call review of draft-campbell-sip-messaging-smime-03

Ben.

> 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.
> 
> 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.

> 
> 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.

How about the following:

OLD:

NEW:

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 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 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 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.

> 
> Page 15, section 10.1, 1st paragraph, 2nd sentence: change "a" to "an" 
> unless "smime" is not pronounced "ess-mime".
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 9 Oct 2018 23:11:16 -0500

> On Oct 9, 2018, at 10:50 PM, Peter Yee <[email-masked]> wrote:
> 
> Ben,
> 

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 k…

You are correct, it should be UAs. Good catch.

Thanks!

Ben.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 25 Oct 2018 10:52:05 +0200

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-masked]> wrote:
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art