Re: [rtcweb] SRTP not mandatory-to-use

[Ted Hardie <[e-mail]>]

Hi Bernard,

The threading must have gotten mixed up here, because the responses
below are to me, not Justin.   Some further discussion in-line.

On Thu, Jan 5, 2012 at 12:03 AM, Bernard Aboba
<[e-mail]> wrote:
>
> Justin said:
>
>
> Are they easier or harder to deploy than SRTP?
>
> [BA] Having been involved in deployment of millions of SRTP endpoints, I
> wouldn't say SRTP is hard to deploy.  Virtually *all* the pain comes from
> key management.
>
> The same thing is true of IKE/IPsec by the way.  When people complain about
> IPsec, they almost always are talking about an IKE issue.
>
>

Thanks for the clarification.  But if we accept the current threat
model (untrusted JS, where we wish to avoid revealing the SRTP keys to
the application), I'm not sure that there is any way to avoid this
pain.


> Justin said:
>
> "If you could provide text for the use
> case/scenarios draft that illustrates one and explain why, that would
> be very useful in moving this discussion forward."
>
> [BA] It's not hard to come up with scenarios where SRTP might be fine, but
> DTLS/SRTP would be burdensome.
>
> PSTN gateways are a good example of that.  Some support SRTP today, and
> almost all of these do SDES.  If we
> insisted, we could probably get some vendors to support ICE too.  But asking
> for DTLS/SRTP (especially a variant
> different from the one implemented in SIP) is highly unlikely.
>

I agree that increasing the number of variants will be a pain for
gateway operators.   If there is something currently is deployed and
meets the threat model, I am sure that there would be interest.  But
shifting to something that reveals the keys to an untrusted part of
the system seems to be the wrong approach for solving the problem, at
least to me personally.



> Justin said:
>
> "Until then, I think the Danvers Doctrine pretty plainly pushes us to
> make SRTP mandatory to implement."
>
> [BA] No objection to mandating implementation here.  SRTP is implemented in
> sub-$100 devices, so it's no big deal.
>
>
> The key question is whether is whether it is:  always on; default on;
> negotiated on.  I am not
> personally persuaded that "negotiated on" makes for easier debugging
> of the resulting system, at least in the common case.
>
> [BA] I'm not sure how we can avoid the possibility of "negotiation" in
> signaling unless we adopt a pure media security approach (e.g. ZRTP).
> As long as it is possible to use offer/answer, you'll have the potential to
> "negotiate" SDES, DTLS/SRTP (SIP Flavor), etc.
>

Well, we've agreed to offer/answer as the basic model, but I think
we're still discussing whether that means that includes negotiation of
SRTP vs. RTP.

>
> Justin said:
>
> "To me, it increases the number of possible attacks and thus the code needed
> to mitigate them."
>
> [BA] Are you saying that a DTLS/SRTP variant integrated with Oath or other
> identity schemes would require minimal code and would interoperate
> seamlessly???
>
Nope, I'm saying that supporting that *plus* a negotiation that allows
for vanilla RTP means we have to add other protections against bid
down attacks.  Those protections men more code.

Hope that clarifies things,

Ted