Re: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and draft-ietf-avtcore-rtp-security-options

[Richard Barnes <[e-mail]>]

Can we seriously not come up with some general principles here?  There are
already some in the document, e.g., in the IPsec section.

-- In general, SRTP-based solutions are preferable to things that tunnel
RTP over something else, because tunnel solutions have additional
vulnerabilities.
-- In general, mechanisms that provide automated key management are
preferable to things that don't [BCP107]

And it seems like we should clearly deprecate the legacy RTP mechanism
(S3.2), and clearly indicate that new IETF protocols should use DTLS-SRTP
instead of ZRTP (in cases where both are applicable).



On Sun, Nov 3, 2013 at 10:40 AM, Roni Even <[e-mail]> wrote:

> Hi Richard,
>
> I think that the purpose of the security option is as the name says to
> list the options and not recommend anything leaving it to the specific
> deployment like RTCweb to make recommendation. In this case if we try to
> recommend order it may just cause further discussion about the order and
> priority which is what we wanted to avoid in this work in the first place
>
> Roni
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Richard
> Barnes
> *Sent:* 03 November, 2013 8:18 PM
> *To:* Colin Perkins
> *Cc:* [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and
> draft-ietf-avtcore-rtp-security-options
>
>
>
> On Sun, Nov 3, 2013 at 8:00 AM, Colin Perkins <[e-mail]> wrote:
>
> On 2 Nov 2013, at 17:12, Richard Barnes <[e-mail]> wrote:
>
> On draft-ietf-avt-srtp-not-mandatory:
> I have reviewed this draft in preparation for IETF Last Call and IESG
> processing.  Clearly, this is not the best moment in history to be making
> this sort of argument, given the increased focus on .  However, I think
> this document makes the case pretty clearly.  It helps to have
> draft-ietf-avtcore-rtp-security-options as a positive statement to go
> alongside this document.
>
>
>
> Note that the srtp-not-mandatory draft is explicitly not saying "strong
> security is not mandatory", rather it's saying that "strong security is
> mandatory, but the appropriate way of providing it depends on the context,
> and SRTP is not always the answer".
>
>
>
> I agree.  It helps though, to be able to say "SRTP is not always the
> answer ... but something in this set of things should be."
>
>
>
>
>
> On draft-ietf-avtcore-rtp-security-options:
> I have reviewed this draft in preparation for IETF Last Call and IESG
> processing.  One question to discuss briefly before IETF LC:  My major
> concern is that it seems like there's a lot of old stuff in here.  Has the
> WG considered explicitly marking each of the mechanisms with some sort of
> recommendation level?  I would like to avoid having someone choose SDES in
> a case where they could use DTLS-SRTP, for example.
>
>
>
> Such recommendations would be very helpful, but depend on the scenario.
> Section 5 gives some pointers, but really we need security architecture
> drafts for particular use cases of RTP (like the WebRTC security arch, for
> example).
>
>
>
> I agree that if you're going to make detailed recommendations, you need
> more specifics.  It seems like you could provide some general guidance
> though.  Could we something like the following?
>
> -- Arrange the mechanisms in the document in an ordered list
>
> -- "If more than one mechanism would work for your application, use the
> higher-pref one"
>
> -- Throw certain things in a NOT RECOMMENDED bucket, like ZRTP and the
> legacy stuff in S3.2
>
>
>
> Part of the advice should also be a reference to BCP 107 [1], "Guidelines
> for Cryptographic Key Management".  Namely, things that provide automated
> key management should be preferred over things that don't.
>
> --Richard
>
>
> [1] <http://tools.ietf.org/html/bcp107>
>
>
>
>
>
>
> Colin
>
>
>
>
>
>
>
>
>
> If the authors could follow up on that one point, we should be able to get
> these both into LC soon.
>
> Thanks,
>
> --Richard
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>
>
>
>
>
> --
>
> Colin Perkins
>
> http://csperkins.org/
>
>
>
>
>
>
>
>
>