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