[Simple] draft-ietf-simple-msrp-cema-05 WGLC comments

[Ben Campbell <[e-mail]>]

(as individual)

Hi,

Here's my WGLC comments on draft-iet-msrp-cema-05. I will focus first on the new security language, but I still have a few comments on the rest of the document. I also have some general editorial comments for the whole document.

Substantive Security Considerations Comments:

-- 7.1, and general:

I'm still uncomfortable with the language that says (or implies) that CEMA enables e2e security in general. In fact, it enables it in a some very specific use cases, namely when you have middleboxes that behave exactly as described in this document--in particular, when they transparently forward TLS, _and_ where direct e2e TLS connections are prevented by some aspect of the provider's architecture (e.g. the middlebox use is required by policy, e2e connections are prevented by NATs, etc.)

But even then, the fact that the endpoints have no way of telling whether the middlebox actually tunnels TLS vs acting as a TLS b2bua makes me very skeptical of any claim of enabling e2e protection. I think
 that, if the endpoints can't _prove_ the protection is e2e, then it has to assume that it is _not_ e2e.

-- 7.1, last sentence "If the key management depends on trust in the signaling plane, the Middlebox is by definition trusted, but the security is still increased as the cleartext is not available in the Middlebox."

The first half of that sentence needs elaboration, particular in light of the other assertions that fingerprint based authentication implies trust in the signaling plane. Are you talking about trust that the signaling plane authentication of endpoints is in fact true, or trust in whether the offer/answer has not been tampered with? It seems to me that something like RFC4474 can use fingerprint authentication of the media session with at least minimal trust in middleboxes.

I think it would help to open the security considerations section with a subsection that explains the trust assumptions for CEMA in more detail

-- 7.2: "For backward compatibility, a CEMA-enabled MSRP endpoint MUST implement TLS."

Why is this for "backwards compatibility"? Seems like you want it whether or not you care about backwards compatibility.

-- 7.4, 2nd paragraph: "This can e.g. be hop-by-hop cryptographic protection or cryptographic access protection combined with physical trust in other parts of the signaling plane."

I'm not sure what you intend by this sentence. Should I infer that a hard shell soft center model of protection is good enough? What are the trust implications for hop by hop? What do you mean by access protection?

It seems like the real point is you _can't_ use end to end integrity protection for signaling across middleboxes, with or without CEMA.

-- 7.4, 3rd and 4th paragraphs:

How can a user determine which case (e2e TLS vs TLS b2bua) is in effect, and decide whether to allow it?

-- 7.4, last paragraph: "But this is not an issue as the signaling network is considered trusted by the endpoint (a requirement to use fingerprint based authentication)."

I don't think I accept that statement in general. (see previous comment for 7.1 about trust in middleboxes)

I think the way this is being presented involves some dog-wagging. It's not so much that the end user wants to trust the middleboxes as much as it is an operator that won't let calls complete if they don't anchor on a middlebox. This is a fairly coercive definition of trust.

-- 7.5, 2nd to last paragraph: "Alternate key distribution mechanisms...may become ubiquitous enough to solve the key distribution problem in the future."

Do we believe RFC 6072 is that ubiquitous _now_? This seems like a dodge to avoid a normative downref. If so, lets not hide it behind "ubiquity". Perhaps the text should read "may become sufficiently standardized..."

-- 7.5, last paragraph: "Some of these options require trusting the service provider, but those issues are beyond the scope of this document."

Isn't this entire document predicated on the idea of endpoints trusting the provider?

-- 7.7, 3rd paragraph: "Signaling over a local or closed network MAY be trusted."

That's a broad statement to make without a considerably longer and more nuanced discussion. As it stands, it seems to encourage a hard-shell-gooey-center approach to security.

-- 7.7, 4th paragraph: "It should however be noted that using fingerprint based authentication over an insecure network increases the security compared to unencrypted MSRP as this makes it harder to perform an man-in-the-middle attack."

You don't even need a MiTM attack if MSRP is used without protection


*** Other substantive comments:

-- 4.2, 4.3, and 4.4: I'm still afraid that sections 4.2, 4.3 are not going to result in interoperable implementations. The various efforts to decide you can still use CEMA even when the peer does not advertise it remind me of the rules of Fizzbin ( http://en.wikipedia.org/wiki/Fizbin#Fizzbin ). Adding in the need to resolve names to IP addresses for comparison purposes in 4.4, I have to ask if we really think the benefit is worth the complexity? Can it be streamlined somehow?

-- 4.2: Step 2:

Doesn't the offerer insert a setup attribute whether or not it uses a relay?. The value changes, but it uses the setup attribute either way.

-- 4.2, step 3 on receipt of answer:

If I read steps 1 and 3 right, the first covers the case of c/m not matching path where the offerer is passive, and the 2nd covers the case of  c/m not matching path and the offerer is active. That's basically all cases where c/m don't match path, isn't it?



*** Editorial Comments:

--1, 2nd paragraph" "middleboxes must read the message"

Just read? Or parse, or modify?

-- "address:port"  (recurs throughout document)

address and port. 

-- "c/m- line"  (recurs throughout document)

c and m-lines, or c-line and m-line. (i.e. don't use "/" as a conjunction)


-- 1, 3rd paragraph: "...that normally result in negative performance impact"

_which_ normally _results_...

-- 2, "Fingerprint Based TLS Authentication: An MSRP endpoint..."

I don't think Fingerprint based TLS authn _is_ an endpoint--it's an action. (repeats for name-based..)

--2, "Name-Based..."

Definition is hard to parse. I think the point is two-fold. The endpoint uses a trusted CA to establish the validity of the peer certificate, then compares the SAN of the peer certificate has a match for the peer's  MSRP URI.

--2, "MSRP B2BUA" "... terminates an MSRP connection from one MSRP endpoint and reoriginates that connection..."

s/connection/session

-- "...SIP B2BUA terminates a SIP session...

s/session/dialog  (or transaction).

-- 4.2, step one  on receipt of an answer:

I have trouble parsing this

-- 4.2, step 3 on receipt of an answer

-- 4.4, paragraph 6 (Note) : "... MSRP URI must always contain a port."

... when used in an SDP path attribute.

-- 6.2, 1st paragraph: "... where the offerer does not support the CEMA extension."

Doesn't that preempt some of the endpoint workarounds for when the peer does not advertise CEMA?


-- 7.7, 2nd paragraph" "...may be hard for the endpoint to decide."

Decide what?