Ballot for draft-campbell-sip-messaging-smime
Yes
No Objection
Recuse
Note: This ballot was opened for revision 03 and is now closed.
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.
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.
Thank you for addressing my DISCUSS.
I am an author.