Re: [Perc] Question on diet Design?

[Eric Rescorla <[e-mail]>]

On Wed, Mar 22, 2017 at 10:42 AM, Paul E. Jones <[e-mail]>
wrote:

> Ekr,
>
>
>> Assuming we could still convey the ROC in the clear (it's not really
>> secret), then I'd like to hear your suggestion.
>>
>
> Replace EKT with a fixed block consisting of:
>
> 1. A centrally assigned endpoint ID [you need this to avoid two-time pad]
> 2. The ROC (if needed)
>
> The per-sender key then can be computed as KDF(K_g, ID) [0]. Note that you
> don't need to
> send this block that frequently, you can use the same algorithm you use
> for EKT, though it's
> also pretty small, so maybe easier to just send all the time.
>
> I haven't been thinking about this for very long, so I could of course
> have something grievously
> wrong and insecure, in which people should point and laugh. One potential
> concern is
> that an attacker can send some incredibly large ROC and thus cause you to
> crank the KDF
> forward a zillion times. I believe that currently anyone who has K_g can
> do this, so requiring
> this block to be MACed with K_g should address this problem.
>
> -Ekr
>
> [0] Note, this assumes I am remembering how the ROC works, which, IIRC, is
> just that it tells you which generation of SRTP keys to derive from the
> master.
>
>
> 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?

-Ekr

The ID, steam_id, and ROC values would need to be conveyed in the RTP
> packet (or RTCP packet -- though I'd prefer to try to avoid putting such
> info into RTCP) to ensure that the receiver gets the information it needs
> to decrypt the flow.  So, it's not clear that there is an advantage to this
> approach.  The size of the EKT field might be smaller, but we could make it
> smaller now if we wanted (removing extensibility and length fields).
>
> Perhaps I'm missing an important advantage?
>



> Paul
>
>