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
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: Wednesday, September 17, 2014 5:18 PM
To: Igoe, Kevin M.
Cc: draft-ietf-avtcore-srtp-aes-gcm(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
gen-art(_at_)ietf(_dot_)org Team (gen-art(_at_)ietf(_dot_)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.
<kmigoe(_at_)nsa(_dot_)gov<mailto: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?
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
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".
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.
[...]
-- 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.
A similar issue came up in Suite B for Secure Shell, and the the original secsh
RFCs were
left unaltered. But that was an informational RFC, not standards track.
======================================================================
===============
-- 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?
Yes, I'd be reluctant to go beyond what is already said in 3371.
======================================================================
===============
-- 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.
Sounds reasonable to me.
======================================================================
=============== 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.
Another good idea.
[...]