Re: [Perc] Question on diet Design?

EKT was deployed and shipped before the PERC WG was started. It was easy to reuse it from an implementation point of view and it remains useful for conferencing even without PERC or DTLS-SRTP because it allows the conference server to move all the participants to same same key to reduce outbound encryption load. 

The other issue driving the design is scheduling when to use keys. We can't easily synchronize when key changes happen, but we can make sure that everyone gets the intermedia key over DTLS and waits a few seconds before they start using it. That way they know everyone has likely received it before thy start using it. 

> On Mar 23, 2017, at 6:45 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
> On Thu, Mar 23, 2017 at 4:31 PM, Paul E. Jones <paulej@packetizer.com <mailto:paulej@packetizer.com>> 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" <ekr@rtfm.com <mailto:ekr@rtfm.com>>
> To: "Paul E. Jones" <paulej@packetizer.com <mailto:paulej@packetizer.com>>
> Cc: perc@ietf.org <mailto:perc@ietf.org>
> 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 <paulej@packetizer.com <mailto:paulej@packetizer.com>> 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
>> 
> 
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc