Subject: RE: [Sipping] :draft-jain-sipping-srtp-00.txt

From: Kavita Jain <[email-masked]>
Date: Wed, 10 Sep 2003 16:16:47 -0400

Dear Mr. Naslund,

Thanks for your input. 

Regarding your DH key concern, the DH secrets are static as the scheme
mentions in the draft. I misunderstood your term, static DH key in my
previous email.  

It will be DH with CBC.

******************************************
 > 3) The proposed scheme talks only about a way to exchange the key to 
encrypt
 > the media packets because of the following two reasons:
 > 	a) Currently SIP does not have this capability.
 > 	b) SRTP does not talk about this issue either.

This is not correct. SRTP provides both integrity
and confidentiality (as well as a number of other config options).
*****************************************************

Nothing gets changed in SRTP. Certainly, SRTP provides integrity and
confidentiality and the proposed scheme is not changing that. The proposed
scheme does not change anything in SRTP at all. All it does is provide the
key to encrypt voice data. Not sure why integrity and confidentiality are in
question. May be I am missing some points here. 

Thanks

kavita

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Mats Näslund <[email-masked]>
Date: Thu, 11 Sep 2003 10:27:31 +0200

Dear Mr. Jain,

Thanks. This clarifies a few questions we had.

> mentions in the draft. I misunderstood your term, static DH key in my

OK. Note though that then you loose perfect forward secrecy (PFS). As
we wrote before, we were "encouraged" to consider removing DH from
MIKEY, considering the computational burden etc. The main reason for 
keeping it in the end was to get one key exchange mechanism *with* PFS
in MIKEY.

Consequently, I hope you understand that I am sceptic to the success
probability of a protocol which *only* provides a DH variant but
*without* PFS.

> It will be DH with CBC.

I trust you mean DH with DES in CBC. Besides the security issues I
raised before with DES, I would then like to add that CBC is not at all
a good mode for wireless scenarios. The last block needs to be padded
with up to 16 octets which defeats most of the gain with IP/UDP/RTP
header compression on the wireless link.

While being of less importance, I also note that CBC has (for wireless)
highly undesired error-propagation properties.

I think this is a mutual misunderstanding, sorry. In any case, if you
intend to use your proposal with SRTP "as is", I don't see that it
provides the necessary (integrity) protetion of SRTP's various
config parameters. Note that even if the key is securly transfered,
security can still be severely compromised in many ways, e.g. 
bidding-down attacks etc.

Cheers,

/Mats