Subject: [Simple] Fwd: MSRP-ACM/SessMatch: Security Considerations and TLS usage

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Mar 2010 10:19:27 -0500

[Adrian sent this to the SIMPLE list, but I don't see any evidence it made it to the list. Apologies if this is a duplicate for people. - Ben]

Begin forwarded message:

> From: Adrian Georgescu <[email-masked]>
> Date: March 10, 2010 5:29:21 PM CST
> To: Simple WG <[email-masked]>
> Cc: Ben Campbell <[email-masked]>
> Subject: Re: MSRP-ACM/SessMatch: Security Considerations and TLS usage
> 
> Hello,
> 
> This analysis belongs to the AG Projects developer of our MSRP UA stack:
> 
> Related to the TLS mutual authentication, the draft is ambiguous. It's rather a discussion, than a clear set of rules. There are things which are left to deduction. The discussion barely touches the cases when a relay is used. An endpoint having a non-NATed address is not the same as an endpoint using a relay (though the draft sort of suggests this) since the relay does not get its hands on the SDP payloads exchanged. There are 16 possible scenarios: each of the two endpoints can be behind a NAT or not (resulting in 4 possibilities), and each of them can use a relay or not (resulting in 4 more possibilities). Finally and each end point can support COMEDIA or not. In total there are 32 possibilities, which need to be inspected (although some of them are really similar).
> 
> It is too complex to be reliable mechanism when it comes to interoperability between multiple vendors, this will rather work well with a single vendor.
> 
> Hope this helps improving the draft.
> 
> Kind regards,
> Adrian
> 
> On Mar 9, 2010, at 1:29 AM, Paul Kyzivat wrote:
> 
>> I looked, and nothing leaped out at me as being problematic.
>> But I have not looked at any of these drafts for ages, so I'm sure I'm not groking the totality of the security mechanism.
>> 
>> 	Thanks,
>> 	Paul
>> 
>> Ben Campbell wrote:
>>> Hi Adam, Paul, and Adrian,
>>> Could I get each of you to make a quick sanity check on the security considerations and TLS mutual authentication related sections of the latest msrp-ACM and session matching drafts? There were a number of updates from the WGLC, and I want to make sure we've not broken anything. The text in question is pretty short.
>>> We'd like to move this forward as quickly as possible.
>>> Thanks!
>>> Ben.
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Mar 2010 10:28:57 -0500

<as individual>

>> Related to the TLS mutual authentication, the draft is ambiguous. It's rather a discussion, than a clear set of rules. There are things which are left to deduction. The discussion barely touches t…

The typical RFC approach is not necessarily to specify every possible use case, but to provide rules from which the use cases can be determined. The idea is to provide primitive operations on which various use cases can be built.

The real test here should be whether the proper behavior for the mentioned scenarios can be unambiguously derived from the normative language here, and in RFC 4975 and 4976. I gather that the commenter believes that they cannot. Can you point to any specific cases that cannot be so determined?