Re: [Perc] Question on diet Design?

[Eric Rescorla <[e-mail]>]

On Thu, Mar 23, 2017 at 4:31 PM, Paul E. Jones <[e-mail]>
wrote:

> Ekr,
>
> The SSRC is used in the IV when encrypting packets, but not directly in
> the KDF to derive k_e, k_a, or k_s.  That said, that will avoid the
> two-time pad problem.
>

Sure, my mistake. In any case, it's not a problem for multiple SSRCs.


Current guidance is that a given key should not be used more than 2^48
> times.  By how much would having 1,000 participants in a conference sending
> a total of 2,000 media flows using keys derived from the same K_g reduce
> key lifetime?
>

These are totally unrelated. The guidance is about the lifetime of a single
GCM key, not about
the keying material from which it was derived.


I'm still struggling with the overall benefit, though.  With both, we have
> a need to exchange keying material, thus a need for DTLS-SRTP + EKT (or
> other) procedures.
>
> With EKT, an endpoint sends its SRTP master key and ROC  periodically.
> AES_Keywrap() doesn't have to be called on every packet, since the
> ciphertext is static.  Other than the size of the EKT field (which we could
> reduce and which is only sent periodically), it doesn't seem like a burden.
>
> What you're proposing will require assignment of a unique participant
> identifier (which we can do over the DTLS tunnel) and sending that ID and
> the ROC periodically in packets.
>
> It seems roughly the same in terms of complexity, with the K_g approach
> (ID || ROC) perhaps using slightly fewer bits on the wire compared to the
> the EKT field.
>
> I'd like to hear others weigh in on pros/cons.  I don't want to send
> negative signals if others favor this approach.  Other than my question on
> key lifetime impact, the K_g approach seems fine.
>

Well, at the moment, I'm just trying to understand what the current design
is supposed
to achieve, and that means getting clear on what keying material you are
trying to
establish.

In that process, I am seeing some things that make me sad in particular;

- Having two key transport phases, which is pretty hard to wrap your head
around,
though perhaps it's just a writing issue.
- Grabbing a DTLS code point (why can't you just shove this in the
application data),
so I'm trying to remove that [0].

So I'm trying to push on what's really needed.

-Ekr

[0] I concede that what I wrote above doesn't do that, but reducing the
number of
key wrap phases might let us do so, for instance by carrying K_g in EKT.


> Paul
>
> ------ Original Message ------
> From: "Eric Rescorla" <[e-mail]>
> To: "Paul E. Jones" <[e-mail]>
> Cc: [e-mail]
> Sent: 3/23/2017 7:12:51 AM
> Subject: Re: [Perc] Question on diet Design?
>
> It's part of the SRTP KDF.
>
> -Ekr
>
>
> On Wed, Mar 22, 2017 at 9:42 PM, Paul E. Jones <[e-mail]>
> wrote:
>
>> Eric,
>>
>> I think what you propose would work, but each stream from a given
>>> endpoint would need to have a unique key since we do not want the any two
>>> media flows using the same key. Thus, I think we'd need:
>>>   KDF(K_g, ID || stream_id)
>>>
>>
>> The SSRC addresses that, no?
>>
>>
>> Yeah, SSRC is fine for that.  We just need to ensure it is a part of the
>> KDF input.
>>
>> Paul
>>
>
>