Re: [Simple] ACM SBC TLS issue [was RE: MSRP-ACM compatibility]

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi, 

>><brainstorming>
>>
>>One way of dealing with this is, as we have discussed, to include 
>>sertificate information in the signalling. In the example above, Alice

>>would be told to check for the name "relay.biloxi.com", instead of 
>>"sbc.atlanta.com".
>>
> 
>I think that's effectively similar to sending the 
>fingerprint; it's just a different thing to match on.

Correct. I used the domain names in order to be able to correlate to
your example :)

>>Another way of dealing with this is of course to say that the
>>intermeidate MUST terminate TLS in this case. If BOTH Alice and Bob  
>>open TCP connections (since Bob is behind a relay, I assume he 
>>would ALWAYS be "active"), the intermeidate may need to terminate TLS
anyway, in
>>order to avoid the handshake collision?
>>
>>
>>Now, one could claim that it is difficult to know what intermediates
>>will do, since they are not standardized. Jon also asked whether we
>>would need to specify a new kind of TLS intermediate.
>>
>>If we want to specify something, I am not sure we need to talk
>>specifically about intermeidates. I think we can be more generic, and
>>e.g. talking about "entities which generate SDP for MSRP". 
>>That would then apply to any type of entity.
>>
>>"An entity which inserts its authority part in the URI of the a=path
>>header needs to ensure that a matching certificate is provided to  
>>other entities which connect to it. This can be achieved by 
>>terminating TLS connections (instead of being TLS transparent) or by 
>>providing correct certificate information in the signalling to other
entities which
>>connect to it."
>>
>>...or something like that. I think that applies to all kind of MSRP
>>entities - including intermediates.
> 
>As I mentioned in SF, I think we should be careful to avoid 
>suggesting that intermediaries lead an endpoint to believe it has 
>end-to-end TLS protection when it does really doesn't.

Even with legacy MSRP it IS possible to insert intermediates (eventhough
they would have to modify the MSRP messages), so you already have the
problem - as you have with any other type of media.

But, in some cases the clients can at least make some assumptions by
comparing the certificate domains with the path attribute domains.

So, in your example above, no matter if the TLS is terminated by the SBC
or the relay, Alice would detect that it's not end-to-end. If terminated
by the SBC, Alice could also detect that it's not even terminated in the
beloxi.com domain.

>One of the reasons for the path attribute in the first place was to
make it clear to endpoints that there were relays in the path. SBCs/ALGs
are generally not that open about their presence.

Sure, but do we really expect the user to really make different
decissions based on that knowledge? Will the user even be informed about
whether there are relays in the path or not? 

If I want to establish an MSRP session with you, I probably wouldn't
care whether you are behind a relay or not. I would trust that the
operator(s) make sure my stuff doesn't end up in the wrong hands.

And, if I have something very very very sensitive to send you, I may
encrypt the payload myself, and not rely on the MSRP provided encryption
- because even if I start looking at the path attributes etc I can still
not be 100% that there is no intermediate somewhere.

></brainstorming>

Regards,

Christer