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

[Richard Barnes <[e-mail]>]

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