Re: [rtcweb] SRTP and "marketing"

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Richard L. Barnes
> Sent: Wednesday, March 28, 2012 12:44 PM
> To: Harald Alvestrand
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] SRTP and "marketing"
> 
> >> I didn't make it to the mic at the meeting today, but I wanted to
> >> express one concern about the possibility of making RTCWEB SRTP-
> only.
> >>
> >> Hadriel mentioned the "marketing value" of having always-on
> >> encryption, this idea that only supporting SRTP will make RTCWEB
> look
> >> like something secure and trustworthy. I'm concerned that this might
> >> not be the case, and in fact that being SRTP-only might effectively
> be
> >> an over-promise, in light of the fact the absence of universal
> >> authentication.
> >>
> >> Hadriel noted that the competitors to this technology are Skype and
> >> Flash, and it's worth considering the security situation with these
> >> technologies, because they kind of bracket RTCWEB. With Skype
> >> (assuming they've designed it properly), there is actually a
> universal
> >> authentication, under a single authority. So you really do know that
> >> you're talking to whatever Skype ID you intend to, and nobody else.
> >> With Flash, well, does anyone expect it to be secure anyway?
> >>
> >> What I'm concerned about in the RTCWEB context is that without a
> >> universal authentication/identity infrastructure, we will end up
> >> *promising* a secure call, but not *delivering* it. I haven't done
> the
> >> analysis, but it does not seem implausible to me that FireSheep-like
> >> vulnerabilities are lurking here.
> > If there are, we need to close them before we ship the specs.
> > Given reasonable practices (such as using only HTTPS for loading the
> > pages and JS libraries), if we can't deliver security (against known
> > attacks), we shouldn't ship the spec.
> 
> I agree that we should lock things down to the extent we can, and I
> think we will be able to do pretty well, using things such as you note.
> 
> But at base, without authentication, you cannot prevent MitM if someone
> is in the right place in the network.  You can just constrain the set
> of
> places from which an MitM can be launched.
> 
> 
> >> So ISTM the "marketing" argument carries with it some serious risks
> as
> >> well as some small possible benefit.
> > Only if we don't deliver.
> 
> Except that "deliver" in this case entails a global
> authentication/identity infrastructure.  And it seems unlikely that
> we'll deliver that in the short run.

We do need a foundation upon which an authentication/identity 
infrastructure can be built.  We know we need one.

That foundation is DTLS-SRTP, and not Security Descriptions.

-d

> 
> --Richard
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb