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. <kmigoe@xxxxxxx> 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? > 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? > > > 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? 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? Or do you expect communities to actually implement central ssrc management? [...] > > -- 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. > In my personal opinion (and the IESG may fee otherwise), if an RFC proposes the existence of a context in which a MUST level requirement in another RFC can be relaxed, then it updates that other RFC. Such an update need not imply that the MUST be relaxed for all purposes--just this one. I might feel otherwise if the modified language had been a SHOULD, since the whole point of SHOULD is to allow for situations where it doesn't apply In this case, it's probably up to the security ADs to make the call. > ===================================================================================== > -- 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? Did you mean for your response to 14.1 to apply also apply here? > > ===================================================================================== > -- 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. I think some readers may take the fact master salt is called out in the first place to imply some need to keep it secret. I know you don't say that, but it might be worth a sentence to emphasize that the draft doesn't take a position on whether it needs to be kept secret in the first place. > > > ===================================================================================== > 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. That's pretty much what I figured. I would be helpful to mention that in the draft. [...]