Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

[Roman Shpount <[e-mail]>]

I think RTP vs SRTP should be handled similarly to HTTP vs HTTPS. If the
current session is secure (started by HTTPS) only secure media should be
allowed, or unsecure connections should only be allowed after the user
consent. If the session is started by HTTP, unsecure media should be allowed
since all the signaling is insecure in the first place. Please keep in mind
that secure media is not limited to SRTP. RTP over DTLS is as or more secure
then SRTP.
_____________
Roman Shpount


On Fri, Sep 9, 2011 at 3:23 PM, Alan Johnston <[e-mail]>wrote:

> Ekr is correct.  If we allow RTP, which I think is a mistake, then
> there is always a downgrade attack.
>
> My point was that if we must support insecure media, we could avoid
> the complexity of CapNeg by not requiring a single pass non-secure
> media negotiation.
>
> - Alan -
>
> On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla <[e-mail]> wrote:
> > On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman
> > <[e-mail]> wrote:
> >> On 9/9/11 10:47 AM, Alan Johnston wrote:
> >>>
> >>>   The default will be SRTP - this can be
> >>> expressed in SDP without CapNeg.  Should the RTCWEB clients choose to
> >>> instead negotiate RTP, then this could be done with a second SDP
> >>> Offer/Answer exchange.
> >>
> >> I believe you've just designed a downgrade vulnerability.
> >
> > Unless I'm missing something, if you (a) support an insecure mode and (b)
> allow
> > negotiation of insecure vs. secure, there's not really any way to
> > avoid a downgrade
> > issue; the attacker can always pretend not to support security and how do
> you
> > know better? Obviously, it helps if you can negotiate the use or non-use
> of
> > media security over a secure-ish signaling channel, but that doesn't
> reduce
> > the threat from the signaling service.
> >
> > Best,
> > -Ekr
> >
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>