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

From: Richard Barnes <[email-masked]>
Date: Sat, 2 Nov 2013 17:12:27 -0700

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.

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.

If the authors could follow up on that one point, we should be able to get
these both into LC soon.

Thanks,
--Richard

---

From: Colin Perkins <[email-masked]>
Date: Sun, 3 Nov 2013 08:00:57 -0800

On 2 Nov 2013, at 17:12, Richard Barnes <[email-masked]> wrote:
> 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 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]
> https://www.ietf.org/mailman/listinfo/avt

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

---

From: Richard Barnes <[email-masked]>
Date: Sun, 3 Nov 2013 10:18:08 -0800

On Sun, Nov 3, 2013 at 8:00 AM, Colin Perkins <[email-masked]> 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."

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

---

From: "Roni Even" <[email-masked]>
Date: Sun, 3 Nov 2013 20:40:18 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Barnes
Sent: 03 November, 2013 8:18 PM
To: Colin Perkins
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and
draft-ietf-avtcore-rtp-security-options

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.

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.

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? 

--Richard

 

Colin

Thanks,

--Richard

 

-- 

Colin Perkins

http://csperkins.org/

---

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:
>> 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
> mandatory, but the appropriate way of providing it depends on the
> context, and SRTP is not always the answer".
>
>> 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.
>
> drafts for particular use cases of RTP (like the WebRTC security arch,
> for example).
>
> Colin
>
>
>
>
>> [email-masked] <mailto:[email-masked]>

---

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: Richard Barnes <[email-masked]>
Date: Tue, 5 Nov 2013 09:17:14 -0800

Can we seriously not come up with some general principles here?  There are
already some in the document, e.g., in the IPsec section.

-- In general, SRTP-based solutions are preferable to things that tunnel
RTP over something else, because tunnel solutions have additional
vulnerabilities.
-- In general, mechanisms that provide automated key management are
preferable to things that don't [BCP107]

And it seems like we should clearly deprecate the legacy RTP mechanism
(S3.2), and clearly indicate that new IETF protocols should use DTLS-SRTP
instead of ZRTP (in cases where both are applicable).

On Sun, Nov 3, 2013 at 10:40 AM, Roni Even <[email-masked]> wrote:

> 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:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Richard
> Barnes
> *Sent:* 03 November, 2013 8:18 PM
> *To:* Colin Perkins
> *Cc:* [email-masked]; [email-masked];
> *Subject:* Re: [AVTCORE] AD review: draft-ietf-avt-srtp-not-mandatory and
> 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."
>
>
>
>
>

---

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 6 Nov 2013 19:13:43 -0800

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

>>     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).
> 
> 

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

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 12 Nov 2013 16:12:22 +0100

Richard and WG,

We have updated the RTP Security Options document. This adds three
guidance sub-sections regarding automated key-management, tunnels vs
end-to-end security and plain text key considerations.

I also fixes a missing reference. All visible in the diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-security-options-09

I hope everyone can take a look at these changes and react if they are
wrong or non-acceptable.

Cheers

Magnus

On 2013-11-03 01:12, Richard Barnes wrote:
> making this sort of argument, given the increased focus on .  However, I
> think this document makes the case pretty clearly.  It helps to have

-- 

Magnus Westerlund

---

From: Richard Barnes <[email-masked]>
Date: Fri, 22 Nov 2013 16:59:40 -0500

Hey Magnus,

That looks much better.  Thanks for the text.  I will put this out to LC
along with -srtp-not-mandatory.

--Richard