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

Dean, 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Dean Willis
> Sent: 30 March 2009 19:18
> To: Hadriel Kaplan
> Cc: SIP List; Francois Audet; Jon Peterson
> Subject: Re: [Sip] francois' comments and why RFC4474 not 
> used in the field
> 
> 
> On Mar 30, 2009, at 1:00 AM, Hadriel Kaplan wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: [email protected] [mailto:[email protected]] 
> On Behalf  
> >> Of Dean
> >> Willis
> >> Sent: Monday, March 30, 2009 12:09 AM
> >>
> >> 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.
> >
> > No, that's not at all the main reason.  RFC4474 is already not end- 
> > to-end.  It's signed by a middlebox in the originating domain, and  
> > verified by a middlebox in the terminating domain.  There is ample  
> > opportunity to change the SDP at either of those domains to 
> perform  
> > lawful intercept.
> 
> RFC 4474 can be used end to end. It all depends on which cert 
> is used  
> to sign the identity, where that signing occurs, and where it gets  
> checked. For stupid legacy phones, it can be signed and checked at  
> middleboxes operating under some level of transitive trust. For  
> smarter devices, it happens in the endpoint.
> 
> Signing and checking at the endpoint, coupled with the DTLS  
> fingerprint check. enables end-to-end verification of media 
> integrity  
> and privacy. Once you start ripping these signatures out in 
> the middle  
> of the network and replacing them, we have lost this absolutely  
> critical property. If transit providers even think it MIGHT be  
> reasonable to rip out the signatures, then we have lost the key  
> functionality. Removing signatures MUST BE FORBIDDEN. Adding 
> new ones  
> might be ok.
> 
> I might be willing to compromise on the mechanism (I've already  
> proposed several potential approaches to doing so), but I'm 
> unwilling  
> to compromise on the fundamental requirement for this end-to-end  
> applicability.
[JRE] Yes, that is a positive feature of RFC 4474, the fact that it can
be used end-to-end, end-domain-to-end-domain, or even end-domain-to-end
or end-to-end-domain. In other words, the authentication and
verification functions can be in the endpoint or an end domain
intermediary.

John

> 
> --
> 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