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

2018-10-25 Thread Alissa Cooper
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  wrote:
> 
> 
> 
>> On Oct 9, 2018, at 10:50 PM, Peter Yee  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:b...@nostrum.com]
>> Sent: Tuesday, October 09, 2018 9:55 AM
>> To: Peter Yee
>> Cc: gen-art@ietf.org; draft-campbell-sip-messaging-smime@ietf.org; 
>> i...@ietf.org
>> 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  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
>>> 
>>> .
>>> 
>>> 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 

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

2018-10-09 Thread Ben Campbell


> On Oct 9, 2018, at 10:50 PM, Peter Yee  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:b...@nostrum.com]
> Sent: Tuesday, October 09, 2018 9:55 AM
> To: Peter Yee
> Cc: gen-art@ietf.org; draft-campbell-sip-messaging-smime@ietf.org; 
> i...@ietf.org
> 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  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
>> 
>> .
>> 
>> 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 

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

2018-10-09 Thread Peter Yee
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:b...@nostrum.com] 
Sent: Tuesday, October 09, 2018 9:55 AM
To: Peter Yee
Cc: gen-art@ietf.org; draft-campbell-sip-messaging-smime@ietf.org; 
i...@ietf.org
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  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
> 
> .
> 
> 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 

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

2018-10-09 Thread Ben Campbell
Hi Peter, thanks for your review. Please see inline:

Ben.

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