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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Nov 2013 09:42:15 +0100

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 <[email-masked] <mailto:[email-masked]>>
> 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
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/avt
>
>
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 5 Nov 2013 08:01:41 -0800

Hannes,

The goal of the draft is not to justify a lack of strong security. It is to explain why SRTP is not an appropriate mechanism for providing strong security for all use cases of RTP, and highlight that some scenarios need alternative strong security mechanisms. The rtp-security-options draft talks about what those options might be. If there are sections in the draft that don't make that clear, please let me know, and we can try to improve the text. 

The draft says nothing about the cipher suites to be used. Both SRTP and the other security options mandate strong cipher suites, and there are no proposals to change that.

Colin

On 5 Nov 2013, at 00:42, Hannes Tschofenig <[email-masked]> wrote:
> 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
> 
> 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 
> 

-- 
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 5 Nov 2013 10:15:59 -0800

> could be said about many other protocols the IETF develops, even about

I strongly disagree with that. TLS is a solution you choose to apply or
not. If your RTP application is a multicast one, then we can't do
DTLS-SRTP, because it is can't function in such an environment. Similar
observations can be made about a number of different deployment cases.

> style. I believe I understand the motivation for Magnus.

My motivation for writing SRTP-not-mandatory document was as WG chair to
not have to argue with the Security ADs each time an RTP document passed
the IESG about the security sections. If you are doing an RTP extensions
you need to discuss what that implies security wise and what security
requirements it has. However, it is not the appropriate place to mandate
a particular solution and key-management.

What have been missing in IETF is to write the different "This is what
you shall do, given that your RTP application class is foo". There is
clearly a need for such a document for SIP established sessions. But I
don't volunteer to write it.

If you look at draft-ietf-mmusic-rfc2326bis, that actually normatively
require anyone supporting RTP with RTSP 2.0 to implement SRTP and MIKEY
based keying because that makes sense for RTSP.

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: [email-masked]
----------------------------------------------------------------------