Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-SRTP)

[Igor Faynberg <[e-mail]>]

On 4/5/2012 1:07 PM, Fabio Pietrosanti (naif) wrote:
> ...
> Well, the main point is that DTLS-SRTP claim to provide end-to-end
> encryption, however the user is not able to deliver "end-to-end security" .
>
> end-to-end encryption != end-to-end security .

Yes, so far this is how I read the present state of affairs.  We had a 
very interesting meeting with BrowserID people, but it was too short--at 
least for me--to figure everything out.

I find the issue of self-signed certificates problematic, too.

DTLS-SRTP would provide end-to-end security though if 1) the end points 
had a common PKI chain of trust or 2) if each of them could be 
authenticated to another by an assertion from a trusted IdP.  In neither 
case there would be a key escrow, right?

A level below is the KDC (Kerberos-like) arrangement.  Here both end 
points would need to trust the KDC, and  there are serious business 
cases for that.




> ...
> This bring a misleading concept on DTLS-SRTP in WebRTC because it's
> referred as end-to-end encryption, but it doesn't provide end-to-end
> security like other encryption technologies does (ZRTP, OpenPGP, OTR, etc).
>
> DTLS-SRTP rely on third party for security verification.
>
> DTLS-SRTP = end-to-site security
> SRTP-SDES = end-to-site security
> ZRTP = end-to-end security
>
> This means that DTLS-SRTP, from a trust-model point of view, does not
> provide end-to-end security because there will always be a trusted third
> party able to authorize Man in the Middle to do eavesdropping.
>
> > From that point of view SDES-SRTP provide very similar warranty, except
> that you have to trust only 1 third party rather than 2 third party.

Yes, now I understand what you were saying. I agree.  SRTP-SDES is, in 
fact, what should work with KDC.

And, to throw oil to the fire, did take a look at IBAKE RFCs?  This 
provides an interesting example of what you call end-to-site.

Igor