Francois Audet wrote:
I think that there is a lot of confusion around putting together identity and integrity. It is not that I must have one for the other. I can have identity without integrity of SDP and still be in position to accept/decline a call based on who is calling me. If I'm worried about media confidentiality, I can add zRTP.

If relying on dead-beat end-users for enforcing security, then
sure, you can use ZRTP. Those end-users are the same guys who
keep clicking accept anytime theirs browsers tell them the certificate
is invalid.

When the private conversations unlawfully recorded gets leaked,
or when somebody impersonates an important person, the individual who gets fired is the IT guy who recommended using ZRTP.

Anyways, I digress.

I think the argument for the proponents of RFC 4474 is that
you can not separate identity from media security. If 4474
allows for intercepting the media, than the identity of the
interlocutor is wrong.

That's indeed the argument. In other words, how can be message
of certain origin valuable if of uncertain content. Are you
sure to whom you are sending your RTP packets to? (Ironic
answer: with 99% probability to your enterprise's ALG ;-))

The argument is valid, but unfortunately I believe SDP rewriting
is here to stay, in places we have not anticipated. These SDP
rewriters render the extra security value much less useful then
we have hoped for.



What you are arguing for is a mechanism that asserts the
identity of the sender of the signalling only (SIP), and not the
media.

Yes.


Perhaps this what we need. I believe that the current DTLS proposal
actually relies on 4474 for the fingerprinting. I guess we would
need something else.

That's indeed a problem. Could be addressed by DTLS doing it somewhere
else or 4474 changed to cover less.

-jiri


It's almost as if we would need something like 4474 between originating
domain and Service Provider, and then 4474 again between Service provider
and destination domain.

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip

Reply via email to