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.
=====================================================================================
----------------+--------------------------------------------------
Kevin M. Igoe | "We can't solve problems by using the same kind
kmigoe(_at_)nsa(_dot_)gov | of thinking we used when we created them."
| - Albert Einstein -
----------------+--------------------------------------------------
-----Original Message-----
From: Ben Campbell [mailto:ben(_at_)nostrum(_dot_)com]
Sent: Thursday, September 11, 2014 7:20 PM
To: draft-ietf-avtcore-srtp-aes-gcm(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: gen-art(_at_)ietf(_dot_)org Team (gen-art(_at_)ietf(_dot_)org); IETF
Discussion
Subject: Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you may
receive.
Document:
draft-ietf-avtcore-srtp-aes-gcm-14
Reviewer: Ben Campbell
Review Date: 2014-09-11
IETF LC End Date: 2014-09-11
Summary: This draft is almost ready for publication as a proposed standard, but
there are open issues that should be addressed first.
Note: I have not attempted to verify the pseudocode fragments in this draft.
Major issues:
[Note: I am on the fence on whether the following is a major or minor issue. I
put it in the major section to draw attention to it, but I am prepared to
downgrade it if discussion seems to suggest doing so.]
-- Section 9.4, 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. This
seems like a pretty big architectural change to the handling of SSRC that would
likely be an impediment to deployment. I also have to wonder if such an SSRC
manager could become a central point of attack.
I note that RFC 3711, section 9.1 talks about what I gather is the same issue,
and does not seem to call for a central SSRC manager. Are the requirements here
that different than for 3711?
Minor issues:
-- General:
There are a number of instances of 2119 normative language that I suspect do
not define new normative requirements as much as repeat normative requirements
from elsewhere (either in this draft, or from elsewhere.) This creates
confusion on which text is authoritative, and creates an opportunity for
inconsistent normative statements about the same thing. I strongly suggest that
anytime you repeat or summarize normative text that is authoritatively stated
elsewhere, you either use descriptive (non-normative) language (e.g., Foo is
required to bar the baz), or clearly attribute the source (e.g. [XXX] says that
foo MUST bar the baz.)
-- 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.
-- 8.1:
If this draft contradicts normative language from RFC 3711, it should
explicitly update 3711.
-- 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?
Also, can you offer a definition of "properly erased"?
Nits/editorial comments:
-- There is a citation of RFC2675, but it doesn't appear in the references.
-- The abstract is out of place (Should be at beginning.)
-- section 1, third paragraph: "... provides a high level of security ..."
That may change over time. I suggest prefacing with "At the time of this
writing..."
-- section 3, last paragraph:
Please expand IV on first mention.
-- section 5.3, last paragraph:
First and last sentence seem to contradict each other.
-- 15.1:
The IANA registration section for the SDES crypto-suites is oddly stated. That
registry is just a table; the use of the srtp-crypto-suite-ext ABNF
construction may be confusing.