Re: francois' comments and why RFC4474 not used in the field

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