SIP-Based Messaging with S/MIME
draft-campbell-sip-messaging-smime-05

Thanks for the work everyone did on this document.

---------------------------------------------------------------------------

Title:

The RFC editor considers "SIP" to be well-known enough to no longer require
expansion. You may want to shorten it to simply "SIP-Based Messaging with
S/MIME".

See https://www.rfc-editor.org/materials/abbrev.expansion.txt

---------------------------------------------------------------------------

§1:

>  The Open Mobile
>  Alliance (OMA) Converged IP Messaging (CPM) [CPM], [RCS] system uses
>  the SIP Message Method for short "pager mode" messages and MSRP for
>  large messages and for sessions of messages.

I am a bit confused about why the RCS reference appears in this sentence.

---------------------------------------------------------------------------

§1:

>  the SIP Message Method for short "pager mode" messages and MSRP for

Nit: MESSAGE

>  these notifications are security sensitive.  For example, such

Nit: "security-sensitive"

>  S/MIME is not in common use for SIP and MSRP based messaging

Nit: "SIP- and MSRP-based"

>  and RFC 4975 in an attempt to make the S/MIME for SIP and MSRP easier

Nit: remove "the" from in front of "S/MIME"


---------------------------------------------------------------------------

§4.3:

Should this section provide guidance to implementers about what to do if they
receive a message that is first encrypted and then signed as in the original
specification?

---------------------------------------------------------------------------

§7.2:

>  SIP user agents (UA) can indicate support for S/MIME by including the
>  appropriate media type or types in the SIP Accept header field in a
>  response to an OPTIONS request

This should probably mention something about the limitations of using OPTIONS in
this way due to the HERFP problem.

---------------------------------------------------------------------------

§7.3:

>  Content-Disposition header "handling" parameter of "required" return

Nit: "header field"

>  certificate.  However, it MAY return a 2XX class response if

Nit: "2XX response" or "200-class response"

---------------------------------------------------------------------------

§9.1:

>  time of this writing, CPIM compliant gateways have not been deployed.

Nit: "CPIM-compliant"

>  metadata in CPIM header fields.  For example, CPM and RCS based
>  service include application servers that may need to insert time

Nit: "services"

>  If such clients need to provide encrypt or sign CPIM metadata end-to-

Nit: s/provide//

---------------------------------------------------------------------------

§10:

>  Some SIP header fields are folded to avoid
>  overrunning the margins.  Folded lines contain leading white space at
>  the beginning of the line.  These folds would not exist in the actual
>  message.

This disclaimer seems unnecessary, given RFC 3261 §25.1:

>  SIP header field values can be folded onto multiple lines if the
>  continuation line begins with a space or horizontal tab.  All linear
>  white space, including folding, has the same semantics as SP.  A
>  recipient MAY replace any linear white space with a single SP before
>  interpreting the field value or forwarding the message downstream.

---------------------------------------------------------------------------

§12:

There are a set of recently discovered vulnerabilities in S/MIME in general
that allow exfiltation of encrypted information from S/MIME clients. One of
these is exclusively a problem with the way that clients have implemented
S/MIME, and can be addressed by taking proper steps in the clients to parse
MIME bodies prior to parsing HTML. The other one seems somewhat more tricky to
address, and is a foundational flaw in S/MIME. Both a tax require access to
the message that is going to be intercepted, so the use of hop-by-hop
encryption helps significantly. I would think that both of these deserve at
least some treatment in the security section of this document. See
https://efail.de/ for additional details.

Thanks for doing this work.

Just for my own background, does the "updates RFC 3261" also improve the ability to implement and deploy S/MIME for other SIP applications?

   While both SIP and MSRP provide mechanisms for hop-by-hop security,
   neither provides native end-to-end protection.  Instead, they depend
   on S/MIME [RFC5750][RFC5751].  However at the time of this writing,
   S/MIME is not in common use for SIP and MSRP based messaging
   services.  This document updates and clarifies RFC 3261, RFC 3428,
   and RFC 4975 in an attempt to make the S/MIME for SIP and MSRP easier
   to implement and deploy in an interoperable fashion.