Jiri, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Jiri Kuthan > Sent: 30 March 2009 18:00 > To: Dean Willis > Cc: SIP List; Francois Audet; Jon Peterson > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > Dean Willis wrote: > > > > On Mar 28, 2009, at 3:02 PM, Jiri Kuthan wrote: > > > >> > >> > >> I'm worried this is only a wishful thinking. While perfectly > >> logical, still even in such constrained setups some bizzar > >> ALGs do in my experience appear in the middle, change SDP > >> and make thus the identity worthless. > > > > > > If they change the SDP, they've changed the identity > assertion. They > > need to re-assert. There might reasonably be a need to have > a stack of > > assertions with diffs, so one could go back and see the > original SDP, > > with its original key fingerprint and original verifiable > signature, but > > just changing stuff and pretending the associated identity > assertion > > hasn't changed is fundamentally bogus. > > Hi Dean, > > My argument has been that including SDP's IP address and port numbers > in message integrity check is not an identity assertion, but > a protocol > shortcoming (certainly well-meant, but making things hard to deploy). > I really think that identity and integrity of SDP are two > different things. > > Or do you think that these elements somehow belong to > identity assertion? > > > > > The MAIN reason, it seems to me, to want to change the SDP (and > > especially the key fingerprint) undetectably is to enable intercept > > (lawful or otherwise) without detectability. That just won't do. > > In the field, the desire to change SDP I have witnessed is > due to NATs. > We don't have TURN & ICE in the field and I'm quite worried that very > few care today. In fact, SDP rewriting has been in use for so > long, that > I consider TURN's success chances very marginal. Other I have > witnessed > is transcoding. > > To make it clear: I'm not opposed to all sorts of integrity > protection. > I'm just worried that if we try to solve identity in a single package > with integrity of ever changing SDP, we will unlikely succeed. > > > > > Perhaps we only need are two different identity assertions; > one on the > > original SDP with fingerprint, and one on whatever has resulted > > post-modification by the MITM attackers. Intermediate > manipulations by > > yet more MITN attackers might well be worthless. > > > > Let's put it another way: One of the very important things > that RFC 4474 > > does is protect the DTLS/SRTP key fingerprint. Arguably, > its protection > > of the other stuff in the SDP, such as the port numbers and > IP addresses > > used for media, is just a side effect. Of course, changing > the codec > > (transcoding) is going to break DTLS/SRTP quite horribly, > so the codec > > information might as well be protected by Identity. > > > > Would we be willing to accept a model where the fingerprint > is preserved > > across SBCs but the IP address/port number information is > not? I'm not > > saying that would be easy to produce; it would seem to > require a very > > complex modification to RFC 4474's handling of SDP, or > complementary > > fundamental changes to RFC 4474 and the DTLS draft family. > But would it > > get us past this this stone wall? > > Logically yes, integrity of some pieces that are known not to > be useful > to be rewritten would be ok. > > The practicability is of course another question, on which > many may have > different opinions. Should mine be asked, I would be in favor of using > confidentiality protocols that do not have dependencies in general, > and dependencies on protocols with unenforceable identity in > particular: > zRTP. > > > > > If not, why not? And you're going to have to convince me > that you're not > > just building a phone-tapper protocol here . . . > > I haven't been working on a phone-tapper, even though a media-relay or > transcoder could be labeled so for marketing purposes :-) > zRTP actually > makes it gracefuly through media relay while confidentiality remains > preserved. [JRE] I am concerned about more than just confidentiality of media. I believe integrity protection (of certain data) and authentication are also important. There is only limited value on agreeing an encryption key with an unknown entity.
John > > -jiri > > > > > -- > > Dean > > > > _______________________________________________ > 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 > _______________________________________________ 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
