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

>> -- Throw certain things in a NOT RECOMMENDED bucket, like ZRTP and 
>> the legacy stuff in S3.2

>For ZRTP what are your grounds for issuing the NOT RECOMMENDED. I think 
>we accurately describes its status.

Regarding the security aspects, I am not aware of any known weaknesses in ZRTP. In fact, if used in a scenario without prior e2e shared cryptographic secrets (which is probably the most common use case for both ZRTP and DTLS-SRTP) then ZRTP provides e2e authentication by using SAS, while DTLS-SRTP in this scenario only provides opportunistic encryption.

/John

-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund
Sent: den 7 november 2013 04:14
To: Richard Barnes; Colin Perkins
Cc: draft-ietf-avt-srtp-not-mandatory@tools.ietf.org; avt@ietf.org; draft-ietf-avtcore-rtp-security-options@tools.ietf.org
Subject: Re: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and draft-ietf-avtcore-rtp-security-options

Richard and WG,

See inline

On 2013-11-03 10:18, Richard Barnes wrote:
> On Sun, Nov 3, 2013 at 8:00 AM, Colin Perkins <csp@csperkins.org 
> <mailto:csp@csperkins.org>> wrote:
> 
> 
>     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."

I think you need to say, hopefully something in this set should be. It is not certain that we actually have the security mechanism required for a particular application context.

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

First of all this is an informational document, it was not written as a recommendation document. It is a survey with some general guidelines.

> -- Arrange the mechanisms in the document in an ordered list

According to which application context should that list be arranged for?

> -- "If more than one mechanism would work for your application, use 
> the higher-pref one"

The issue is that one mechanism is more suitable in the context of multicast but, maybe another is more suitable in another application context. And there are relative ordering will vary.

> -- Throw certain things in a NOT RECOMMENDED bucket, like ZRTP and the 
> legacy stuff in S3.2

Section 3.2 says:

This
   method can provide confidentiality but, as discussed in Section 9 of
   [RFC3550], it has extremely weak security properties and is not to be
   used.

Isn't this clear enough? I don't want to use RFC 2119 language in an Informational document that is a description, and not a recommendation document.

For ZRTP what are your grounds for issuing the NOT RECOMMENDED. I think we accurately describes its status.
> 
> 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.

Yes, this we can add to section 4. Securing RTP Applications.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt