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
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
