Subject: [Simple] Comments on draft-ietf-simple-msrp-sessmatch-07

From: Ben Campbell <[email-masked]>
Date: Tue, 19 Oct 2010 20:16:16 -0500

(As individual)

Hi,

I just got around to reviewing the latest sessmatch version. I know this should have happened sooner. mea culpa.

- Summary:

I have issues with this version. I think it goes well beyond the work group consensus in a couple of ways:

1) It makes updates to RFC 4975 that were never discussed in the working group. Some of these are editorial in nature. While I think its reasonable that this draft make statements clarifying how it works with 4975, I don't think those clarifications should be written as updates to the RFC. I admit to replying to other email threads saying that some things in 4975 could be more clear, and that we should clarify them--but I didn't expect that to be done as updates to 4975.

2) It explicitly and implicitly weakens security for MSRP more than in version 06.

- Detailed Comments:

-- General:

On reflection, and after talking to others, I think we should say this draft "extends" RFC 4975 rather than "updates" it.  That might also simplify the approach, where we merely describe different behavior vs trying to "patch" 4975. The reasoning is, if this draft _updates_ 4975, then one could claim that an MSRP implementation that does not also implement sessmatch is actually not compliant to MSRP.  OTOH, if this "extends" it, then if one creates an implementation that does not intend to be deployed with ALGs is still a valid MSRP implementation. I think some might be worried that an extension must be negotiated--but I don't think that's an issue if this is truly backwards compatible.

-- Abstract: 

I think the second paragraph should be moved to the body of the draft and expanded.

-- Section 1, 5th paragraph: "TLS with fingerprint based authentication can be used with such ALGs, however"

I don't agree that is true. In order to have any degress of security, you have to protect integrity of the SDP in order to use fingerprint authentication. Preferably end-to-end. The sort of ALG under discussion won't work with that at all.

-- (same paragraph): "In case TLS name based authentication is used for peer-to-peer MSRP, or MSRP relays with or without TLS are used, ALGs still need to implement MSRP B2BUA functionality in order to prevent MSRP communication from failing"

Need to clean up the terminology here. If you are using an ALG that inserts itself into the media stream by rewriting SDP, you are not using peer to peer MSRP.

-- Section 1, last paragraph:

These networks are not deployed yet, so I'm not sure we can consider anything to be most common. Do we really expect an MSRP chat server or gateway to use fingerprint authentication, when it's perfectly reasonable for them to have trust-anchored certs?

-- section 3: "This document updates sections 5.4 (MSRP Connection Model) and 7.3 (Receiving Requests) of [RFC4975]."

This version does quite a bit more than that.

-- Section 4, general:

It would be helpful to show old and new when replacing whole paragraphs.

-- section 4.2.1: "5th paragraph"

I count it as the 6th. I guess it depends on whether you count indented paragraphs separately. (Do we have an IETF policy on paragraph counting? :-) )

-- Section 4.2.1: "It is strongly RECOMMENDED that MSRP endpoints, when using peer-to-peer MSRP with TLS, use the mechanism described in section 14.4, in order to be able to establish MSRP sessions in networks where Application Layer Gateways (ALGs) are deployed."

On reflection, I object to this change. First, i see no reason to discourage name based authentication when it otherwise makes sense, just because there might be an ALG. Second, this implies a recommendation against e2e protection of the fingerprints in the SDP. We really don't want to discourage that in spec. (We were remiss in letting 4975 go out without making that at least a SHOULD)

-- 4.3.1:

I don't see the point here--you can quibble over semantics but the old and new paragraphs essentially say the same thing. 

I suspect you are concerned than if an ALG changes the authority part to point to itself, then it has to worry about uniqueness across _all_ session_ids, not just the session_ids of the host. But the new text makes no useful difference, as the peer has no way of knowing the host other than by the authority part of the URI. Do we have any idea what the peer might do if it sees a new INVITE with a URI identical to one it is already using?

OTOH, this probably doesn't matter. If the session_id is truly random enough to be hard to guess, then collisions should be extremely rare. 

In any case, I recommend removing this change, and perhaps studying whether we think session_id collisions are something we need to worry about.

-- 4.4.1:

This is essentially an editorial edit to 4975. I don't think that falls within the scope of this draft. It's okay to have clarifying text in _this_ draft that talks about _that_ draft, but you don't have to update 4975 to do that.

If, OTOH, the work group disagrees with me, you could probably make this much simpler by merely saying to insert the note at the end of the section.

-- section 5.2: "An MSRP URI session-id value only needs to be unique within the scope of the MSRP device that created it, so in order to make the session-id unique there is no need to scope its namespace by the MSRP URI authority part."

Again, from the peer's perspective, these two are essentially the same thing.

-- 5.3, paragraph 2:

I don't buy this at all. For one thing, you've already stated an assumption that unprotected MSRP will be common. And even if a MiTM does intend to maliciously modify content, that's still cheaper than maliciously modifying content _and_ having to fix up the To and From paths. And we can hardly consider eavesdropping on communication without the knowledge of either peer to be minor.

-- 5.4, first paragraph: "This specification does not in any way modify the TLS security procedures for MSRP."

This is a false statement, as this draft normatively recommends against trust-anchored certs. It also implicitly discourages e2e protection of fingerprints.

-- section 6: "This document updates 5.4, 6, 6.1 and 7.3 of [RFC4975]"

I don't think that's really an IANA issue.