SIP-Based Messaging with S/MIME

Note: This ballot was opened for revision 03 and is now closed.

(Spencer Dawkins) Yes

Comment (2018-10-23 for -04)
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.

Alexey Melnikov Yes

Adam Roach Yes

Comment (2018-10-23 for -04)
Thanks for the work everyone did on this document.



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




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



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


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



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



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



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



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



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



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 for additional details.

Deborah Brungard No Objection

Alissa Cooper No Objection

Benjamin Kaduk No Objection

Comment (2018-10-25 for -04)
I support Ekr's Discuss.

Section 4.1

nit: please use the same formatting for the id-Ed25519 OID as the other
OIDs in the document.

Section 4.2

   Symmetric key-encryption keys can be distributed before messages are
   sent.  If sending and receiving UAs support previously distributed
   key-encryption keys, then they MUST assign a KEK identifier [RFC5652]
   to the previously distributed symmetric key.

nit: 5622 seems to spell it "KEKIdentifier" (with no space).

nit: id-X25519 OID formatting, too.

Section 4.3

Many readers may be used to seeing encrypt-then-mac used to avoid the
well-publicised security risks of mac-then-encrypt; some discussion of why
sign-then-encrypt is safe in that regard might be in order.

Section 6

   SIP signaling can fork to multiple destinations for a given Address
   of Record (AoR).  A user might have multiple UAs with different
   capabilities; the capabilities remembered from an interaction with
   one such UA might not apply to another.

No discussion of the potential consequences of this for message reception
and display to the user?

Section 8.1

   The sender MUST apply any S/MIME operations to the whole message
   prior to breaking it into chunks.  Likewise, the receiver needs to
   reassemble the message from its chunks prior to decrypting,
   validating a signature, etc.

Are there any new DoS concerns due to retaining such state until the final
chunk is available?

Sectino 9.1

                                                  UAs that support
   S/MIME and CPIM SHOULD be able validate signatures and decrypt
   enveloped data both when those operations are applied to the entire
   CPIM body, and when they are applied to just the CPIM payload.

How do such UAs know which validation procedure to use?

Section 12

                                 In general, the UAS should compare the
   certificate to the identity that it relies upon, for example for
   display to the end-user or comparison to white lists and blacklists.

[just noting we had a long ietf@ thread about potentially offensive
terminology; no action expected]

                  While hop-by-hop protection can mitigate some of those
   risks, it still leaves messages vulnerable to malicious or 
   compromised intermediaries.

Hop-by-hop doesn't address impersonation unless the client requires
hop-by-hop protection, in which case it is still limited protection.

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

(Eric Rescorla) (was Discuss) No Objection

Comment (2019-03-09)
Thank you for addressing my DISCUSS.

Alvaro Retana No Objection

Martin Vigoureux No Objection

(Ben Campbell) Recuse

Comment (2018-10-23 for -04)
I am an author.