Re: [Gen-art] Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14
I am looking at this draft in order to fill in my recommendations for tonight’s IESG telechat. Ben, thank you for your review which pointed out worries (and I agreed with those), and thank you Kevin for the responses (which made sense to me). However, in addition to the major/minor issue discussion, there were several suggested edits. Is there a plan to add them to a new version? I don’t see a new draft version available yet… didn’t see anything that is critical, but I also didn’t want to us to lose discussed improvements. Jari signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14
This is probably my fault. I didn't think it was wise to submit a new version of the I-D until all of the comments corrections had been collected. I didn't want folks trying to review a moving target, especially since a change in paragraph A might affect the interpretation of paragraph B. +-- Kevin M. Igoe | We can't solve problems by using the same kind kmi...@nsa.gov | of thinking we used when we created them. | - Albert Einstein - +-- -Original Message- From: Jari Arkko [mailto:jari.ar...@piuha.net] Sent: Thursday, October 30, 2014 5:20 AM To: Ben Campbell; Igoe, Kevin M. Cc: gen-art@ietf.org Team (gen-art@ietf.org); draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org; IETF Discussion Subject: Re: Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14 I am looking at this draft in order to fill in my recommendations for tonight's IESG telechat. Ben, thank you for your review which pointed out worries (and I agreed with those), and thank you Kevin for the responses (which made sense to me). However, in addition to the major/minor issue discussion, there were several suggested edits. Is there a plan to add them to a new version? I don't see a new draft version available yet... didn't see anything that is critical, but I also didn't want to us to lose discussed improvements. Jari ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14
Kevin: This is probably my fault. I didn't think it was wise to submit a new version of the I-D until all of the comments corrections had been collected. I didn't want folks trying to review a moving target, especially since a change in paragraph A might affect the interpretation of paragraph B. That’s a fine approach. Glad this is all on your radar screen. Thanks. Jari signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14
Ben: Comment inline. As I mention below, the fact that SRTP places key management out of scope is an annoyance when dealing with SSRC management. +-- Kevin M. Igoe | We can't solve problems by using the same kind kmi...@nsa.gov | of thinking we used when we created them. | - Albert Einstein - +-- -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Wednesday, September 17, 2014 5:18 PM To: Igoe, Kevin M. Cc: draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org; gen-art@ietf.org Team (gen-art@ietf.org); IETF Discussion Subject: Re: Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14 Hi, thanks for the response. Further comments inline. I will remove sections that do not appear to need further comment: On Sep 15, 2014, at 3:02 PM, Igoe, Kevin M. kmi...@nsa.govmailto:kmi...@nsa.gov wrote: Ben et al: Here is the reasoning behind some of the issues you raise. At least one of them (SSRC re-use) is security critical. == === SSRC Management: If I read this section correctly, the draft requires central management of SSRC values when you have a master key shared among endpoints in a SRTP session, and goes so far to require authentication of data a central SSRC manager. Yes indeed, having unique SSRC values is a crucial requirement in aes-gcm, since using the same IV (i.e. (ROC,SEQ,SSRC) triple) with the same key K more than once results in two undesirable consequences: 1) It compromises secret authentication value H which is used to authenticate ALL messages that use the key K. 2) It effectively reveals the contents of any packets using this common IV value. Do I undertand correctly that you would need a repeat of all 3 inputs to invoke the problem, not just SSRC, right? Correct. But the SEQ and POC are counters that start at zero, so their presence is not helpful. The IV for the first packet will be (SSRC,0,0), so only the SSRC guards against repeated IVs. Revealing the authentication key is a risk common to aes-gcm and many other AEAD algorithms. But revealing the message content is a risk for any key stream, including AES counter mode. RFC 3711 is willing to accept the compromise of some data, using the SRTP SSRC collision detection process to detect such a compromise after it has occurred. But for my user base, detecting a data compromise after it has occurred is insufficient. For any high value data stream, any data compromise has potentially disasterous consequences Can you elaborate on your user base? Is this draft intended for general use? As you can see from my e-mail address, my mission is to provide information assurance for producers/consumers of US Gov't classified data. My goal is to help bring commercial gear up to a point where it could be used with classified traffic. The classified community isn't alone in needing iron clad security; banks, financial institutions, and many other organizations have an equally serious need for iron clad security (this is my co-author's focus). This I-D started life as an informational RFC, but early on it was requested that this I-D be moved to standards track because of its wide applicability, resulting in the current document. Though I didn't want to specify a mechanism for achieving the goal of having unique SSRCs, the solution I had in the back of my mind was a) Each source has its own key for encrypting its outgoing data streams. b) The key it uses to decrypt incoming data depends upon the originator. c) For a given key K, the burden of preventing SSRC reuse with K depends solely upon the single source forming outgoing data streams using that key. One way or another, using either the current I-D or RFC 3711 with high value data streams requires a mechanism that prevents the use of the same SSRC with two or more data sources that are using the same key on their outgoing data. This decentralizes the burden on SSRC management, but requires each source have its own outgoing data key. If some usage of STTP requires that multiple sources must use the same outgoing data key, a mechanism needs to be in place to impose some discipline on how the members of this subnet assign SSRC values. This holds for both RFC 3711 and the current I-D. Does the source in each source mean the synchronization source? These terms get a little slippery, bit what I mean is the gear responsible for encrypting outgoing data. Let's call this the originating box. I'm not entirely sure I follow you, but I read this to mean you avoid the need for central management of SSRCs by not sharing keys between more than one originator? (that is Assuming so (and my next comment will make no sense
Re: [Gen-art] Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14
Hi Kevin, For the record, based on your comments I now consider the SSRC text to be a minor issue rather than a major one. Comments inline (again, deleting parts that seem closed) On Sep 18, 2014, at 10:30 AM, Igoe, Kevin M. kmi...@nsa.gov wrote: [...] Does the source in each source mean the synchronization source? These terms get a little slippery, bit what I mean is the gear responsible for encrypting outgoing data. Let’s call this the originating box. I'm not entirely sure I follow you, but I read this to mean you avoid the need for central management of SSRCs by not sharing keys between more than one originator? (that is Assuming so (and my next comment will make no sense otherwise): Wouldn't it make more sense to discourage shared keys, since such sharing would create a need for central ssrc management, rather than suggest ssrc management in the first place? Yes, but sadly key management is out-of-scope for srtp. Also a stronger verb that than “discourage” is needed, more like “prohibit”. I don't think the fact that key management is out-of-scope for srtp in general prevents you from offering guidance security critical parts. Or do you expect communities to actually implement central ssrc management? If there is a small network of devices sharing the same key, say a video conference with a handful of participants. One could envision giving each box entering the conference a unique SSRC prefix it uses for any SSRCs it needs to create, once again localizing the SSRC management (save for the task of handing out SSRC prefixes). The bottom line is that there are several ways to mitigate the need for centralized SSRC magament. I agree with you that the key management based approach is far and away the cleanest approach. My sole concern is not reusing an (SRTP, key) pair. Any robust mechanism (i.e. not probabilistic) that achieves this goal is acceptable. I guess my problem is that I took the text as written to suggest that centralized ssrc management was expected to be the normal case. I think it would be perfectly reasonable to say something to the effect of ... MUST not share keys unless a secure mechanism is used to guarantee that SSRC values never collide. I realize that is logically similar to MUST have [ssrc coordination] in order to share keys, but the spin is a bit different. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14
Ben et al: Here is the reasoning behind some of the issues you raise. At least one of them (SSRC re-use) is security critical. = SSRC Management: If I read this section correctly, the draft requires central management of SSRC values when you have a master key shared among endpoints in a SRTP session, and goes so far to require authentication of data a central SSRC manager. Yes indeed, having unique SSRC values is a crucial requirement in aes-gcm, since using the same IV (i.e. (ROC,SEQ,SSRC) triple) with the same key K more than once results in two undesirable consequences: 1) It compromises secret authentication value H which is used to authenticate ALL messages that use the key K. 2) It effectively reveals the contents of any packets using this common IV value. Revealing the authentication key is a risk common to aes-gcm and many other AEAD algorithms. But revealing the message content is a risk for any key stream, including AES counter mode. RFC 3711 is willing to accept the compromise of some data, using the SRTP SSRC collision detection process to detect such a compromise after it has occurred. But for my user base, detecting a data compromise after it has occurred is insufficient. For any high value data stream, any data compromise has potentially disasterous consequences Though I didn't want to specify a mechanism for achieving the goal of having unique SSRCs, the solution I had in the back of my mind was a) Each source has its own key for encrypting its outgoing data streams. b) The key it uses to decrypt incoming data depends upon the originator. c) For a given key K, the burden of preventing SSRC reuse with K depends solely upon the single source forming outgoing data streams using that key. One way or another, using either the current I-D or RFC 3711 with high value data streams requires a mechanism that prevents the use of the same SSRC with two or more data sources that are using the same key on their outgoing data. This decentralizes the burden on SSRC management, but requires each source have its own outgoing data key. If some usage of STTP requires that multiple sources must use the same outgoing data key, a mechanism needs to be in place to impose some discipline on how the members of this subnet assign SSRC values. This holds for both RFC 3711 and the current I-D. = -- References: The draft has normative down ref to RFC 3610. This was not explicitly mentioned in the IETF last call email, and does not appear to be included in the down ref registry. Mea culpa, need to update this. = -- 8.1: If this draft contradicts normative language from RFC 3711, it should explicitly update 3711. Its not so much that tie I-D updates updates as that it deale with a different context. In AEAD an algorithms integrity, is an intrinsic part of the encryption/decryption process, not a separate independent process. RFC 3711 implicitly assumes integrity and privacy are two separate processes, but that it not true of AES-GCM. For non-AEAD algorithms, RFC 3711 is correct in how it handles integrity, but AEAD an algorithm handle integrity in a radically different way and requires the modifications outlined in section 8.1. = -- 8.2 Can you offer guidance on when it might be (or not be) necessary to disguise the length of the plaintext? Especially how that might be known at the SRTP layer? = -- 14.1: Does the master salt need to be kept secret? If the answer is it depends, can you offer guidance? Lurking in section 3.2.1 of RFC 3711 is the following bullet. * a master salt, to be used in the key derivation of session keys. This value, when used, MUST be random, but MAY be public. Use of master salt is strongly RECOMMENDED, see Section 9.2. A NULL salt is treated as 00...0. We took that to say that if the master salt MAY be public, it is also possible for it to be secret. I can not think of any instance in which it needs to be secret, but apparently the authors of RFC 3711 weren't quite so certain. = Also, can you offer a definition of properly erased? Gladly! I mean overwritten, not just dereferenced. It's a bad idea to leave secret values floating around in memory, just waiting for an adversary to read them out. =
