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

["Roni Even" <[e-mail]>]

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/