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

[Dzonatas Sol <[e-mail]>]

On 09/09/2011 12:39 PM, Roman Shpount wrote:
> I think RTP vs SRTP should be handled similarly to HTTP vs HTTPS.

Then that would be the same footsteps as HTTPS, and many of us silently 
do not want that standardized again.

We want the stateful layer, and all routes HTTPS ends that state ("this 
part is done" despite bis).


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

That's like one-way street that wouldn't support "third-party" (use-cases).

> If the session is started by HTTP, unsecure media should be allowed 
> since all the signaling is insecure in the first place.

We can just use OPTIONS here, so this path is not an "attack".

> 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] <mailto:[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]
>     <mailto:[e-mail]>> wrote:
>     > On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman
>     > <[e-mail] <mailto:[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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>    


-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant