Re: [rtcweb] SRTP not mandatory-to-use

[Eric Rescorla <[e-mail]>]

On Tue, Jan 3, 2012 at 4:02 PM, Ted Hardie <[e-mail]> wrote:
> On Tue, Jan 3, 2012 at 3:08 PM, Bernard Aboba <[e-mail]> wrote:
>> Justin Uberti said:
>>
>
>> Requiring SRTP in all circumstances (e.g. offering RTP/SAVP(F) and not
>> falling back or allowing negotiation of RTP/AVP(F)) would not preclude
>> gateways from translating to RTP/AVP(F), without user knowledge.
>>
>> This would result in an illusion of security, compared with an actual
>> negotiation which would apprise the user as to whether security is actually
>> in place.
>>
> I'm a little lost.  In a gateway implemented in a back-to-back user
> agent, won't you end up with the same
> illusion?
>
> The case I think you're talking about is this:
>
> UA--1<-Connection1->B2BUA/Gateway<-Connection-2->UA-2
>
> Do you expect that the gateway would be refuse to use SRTP on one side
> if it intended not to use it on the other?  That seems pretty unlikely
> to me personally, especially in cases where the gateway is to the PSTN
> or a standard SIP system.  Or do you expect that the negotiation would
> be extended so that the gateway somehow indicates that it will not
> SRTP on side two to side one?
>
> If the requirement is SRTP always for WEBRTC, then a b2bUA would have
> to run SRTP on boths ides if both UA-1 and UA-2 were WEBRTC
> applications, but that seems to be what we want.
>
> What am I missing?

I, too, am confused.

Without using the words SRTP, here's the functionality I want, starting from
first principles.

When I have a call, I would like to know to the extent possible:

(a) Who the entity on the other end is.
(b) That the call is secure to that entity, i.e., that we provide
confidentiality
and integrity for the data.

Obviously, once the data is delivered to the entity on the other side, I can
no longer know what the security properties are. At best, they can simply
assert those properties, whether via some technical mechanism or via
a non-technical mechanism ("I promise to keep this conversation secret
and I'm willing to sign an NDA"). That's out of scope for the security services
we know how to offer.

Now, it's clearly the case that there are settings in which there is a gap
between the entity I want to be talking to and the entity that the technology
allows me to provide a secure association to. One such example, as Ted
suggests, is a gateway to the PSTN, which does not provide a secure
channel. What I would like at that point is to be able to:

(a) know that I am talking to the gateway and be able to distinguish this
case from that where I am talking directly to the entity of interest.
(b) have confidentiality and integrity provided for my data in transit to the
gateway.

Obviously, this has the potential to be misleading if the UI is done badly,
but that seems like a result of having a system with differential security
properties, not the result of having always-on crypto for the first hop
link. The only way I know to not have people be potentially confused is
to only have one security level, but since we've already established that
it can't always be secure to the target entity, the only way to have one
security level is to have it be never secure, which also seems rather
undesirable.

-Ekr