Re: [Perc] Question on diet Design?

"Paul E. Jones" <paulej@packetizer.com> Thu, 23 March 2017 23:31 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFF7129991 for <perc@ietfa.amsl.com>; Thu, 23 Mar 2017 16:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkqewpBsj6GJ for <perc@ietfa.amsl.com>; Thu, 23 Mar 2017 16:31:09 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A201273E2 for <perc@ietf.org>; Thu, 23 Mar 2017 16:31:09 -0700 (PDT)
Received: from [192.168.1.20] (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id v2NNV7og011732 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Mar 2017 19:31:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490311868; bh=ORdO6ut8WsXsHn8ct0tueyl4ANYD8YRfWL6tQlcs1eo=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=SrLmvlwYVDsZed+2CqQJtvYcxlEWMNb9iCdGZkv8Vf2EMnkCMtT2UJkHgbE2m0gpa iLDz9zBKOsvAU60sVS1Vl1NfmO0hOmYteHcVxhtb1Dv2dsA9j5QrwPEoP6x+lacRO5 ZXFFU0RIv9pNYA8VfRFYXCDt/feLhqmsw4ffTMCM=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: perc@ietf.org
Date: Thu, 23 Mar 2017 23:31:09 +0000
Message-Id: <em8cc80c10-b9a1-4c1c-9f13-098d43739673@sydney>
In-Reply-To: <CABcZeBNFbpAKu-PkuB+zxxpduJStViJX=_xZD5s7R4ejCMx5FA@mail.gmail.com>
References: <CABcZeBPbFJYyCBUGhtryn1Z6W9feLUiS-sVB+HM7UUUR3-ZbQg@mail.gmail.com> <em918d187a-1839-494c-a969-b298d03965d7@sydney> <CABcZeBNFSmM4VjKzKLmrTzTEMxke=gYzH7x9GuhPcv=gFqRvQQ@mail.gmail.com> <ema2355ca7-fc19-48f6-972e-7dd73ac7a9a9@sydney> <CABcZeBMXWoQ1jeDFGUU2maO3ehJ4Z9-o6_pckUaC_wbmNPPnGg@mail.gmail.com> <emba00a16e-6ca9-41ac-85ae-e53f6115c95c@sydney> <CABcZeBPSATAonu87OaJuUX1QWkuPufi=HpKQQ5AZZB6ZWP759A@mail.gmail.com> <emb912fdf7-1123-46c4-ba3d-8ff4d73e87b2@sydney> <CABcZeBNFbpAKu-PkuB+zxxpduJStViJX=_xZD5s7R4ejCMx5FA@mail.gmail.com>
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
User-Agent: eM_Client/7.0.28492.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBA7094869-EA45-4D72-98AD-2332E7CBEA07"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 23 Mar 2017 19:31:08 -0400 (EDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/2_kAd4sT2g_JbPPjvOomg0Wmxv4>
Subject: Re: [Perc] Question on diet Design?
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing <perc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perc>, <mailto:perc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perc/>
List-Post: <mailto:perc@ietf.org>
List-Help: <mailto:perc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perc>, <mailto:perc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 23:31:12 -0000

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.

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?

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.

Paul

------ Original Message ------
From: "Eric Rescorla" <ekr@rtfm.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: 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> 
>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
>