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@xxxxxxx | of thinking we used when we created them."
| - Albert Einstein -
----------------+--------------------------------------------------
-----Original Message-----
From: Ben Campbell [mailto:ben@xxxxxxxxxxx]
Sent: Wednesday, September 17, 2014 5:18 PM
To: Igoe, Kevin M.
Cc: draft-ietf-avtcore-srtp-aes-gcm.all@xxxxxxxxxxxxxx; gen-art@xxxxxxxx Team (gen-art@xxxxxxxx); IETF Discussion
Subject: Re: Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14
From: Ben Campbell [mailto:ben@xxxxxxxxxxx]
Sent: Wednesday, September 17, 2014 5:18 PM
To: Igoe, Kevin M.
Cc: draft-ietf-avtcore-srtp-aes-gcm.all@xxxxxxxxxxxxxx; gen-art@xxxxxxxx Team (gen-art@xxxxxxxx); 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@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?
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.
[...]