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(_at_)nsa(_dot_)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?
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.
[...]