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

Hi Colin,

I came across this document before and I was really wondering whether 
this is the best story the IETF can come up with.

The argument that RTP is used in a number of different environments, as 
a basis for not offering a solid security story is rather weak. The same 
could be said about many other protocols the IETF develops, even about 
TLS itself.

Have a look at TLS to see an alternative path that one could go instead. 
It mandates a certain ciphersuite and adds the following qualification:

"
Mandatory Cipher Suites

    In the absence of an application profile standard specifying
    otherwise, a TLS-compliant application MUST implement the cipher
    suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the
    definition).
"

If there are deployments or standardization organizations believe that 
they do not require security (because it just runs within their own 
"secure" network* or because it requires a different solution solution, 
like the 3GPP that allows lawful intercept) then that is not a good 
reason for the IETF not mandating something.

I am wondering what motivated you write the document in this specific 
style. I believe I understand the motivation for Magnus.

Ciao
Hannes

(*): As we have recently learned these assumptions may well be wrong, 
see: 
http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html 

Am 03.11.13 17:00, schrieb Colin Perkins:
> On 2 Nov 2013, at 17:12, Richard Barnes <rlb@ipv.sx <mailto:rlb@ipv.sx>>
> 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".
>
>> 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).
>
> 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
>> avt@ietf.org <mailto:avt@ietf.org>
>> https://www.ietf.org/mailman/listinfo/avt
>
>
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>