Re: [rtcweb] Question about srtp_mki in DTLS/SRTP

🔓Dan Wing <dwing@cisco.com> Wed, 14 January 2015 01:24 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC101ACE42 for <rtcweb@ietfa.amsl.com>; Tue, 13 Jan 2015 17:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.21
X-Spam-Level:
X-Spam-Status: No, score=-14.21 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 Il41kPBTfCfQ for <rtcweb@ietfa.amsl.com>; Tue, 13 Jan 2015 17:24:52 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509AF1ACE40 for <rtcweb@ietf.org>; Tue, 13 Jan 2015 17:24:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6267; q=dns/txt; s=iport; t=1421198692; x=1422408292; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=re91Wg3gU2BPjou5Ya2R7/F3aX9HZcgEDVlLKe3eP4s=; b=Rgo8PShgPm7cPD2wrOGRBgPZyi7yJHRXP1Ty/OJNHTx5mFBfvoaW8PAt ht3qG54yfXHhn2LOWQddaHWUfh7dwKJbCzEC5jo10/K8xWR+UXVab9FKx gviprAAqqVfZIzLwXs9kTQ2oLMDve0PBtvZYG/3lO30PuhuQEw1e6M5Vp I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsFABvEtVStJA2N/2dsb2JhbABbgwZSWMYchXECgRhDAQEBAQF9hA0BAQMBeQULC0YhNgYTiBgDCQgNzAgNg2MBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI1PgioHgxaBEwWJZoghhASBRIYag2WCGYVkIoQPHTEBAYJBAQEB
X-IronPort-AV: E=Sophos;i="5.07,753,1413244800"; d="scan'208,217";a="113042705"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 14 Jan 2015 01:24:52 +0000
Received: from [10.24.147.250] ([10.24.147.250]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t0E1OofV027307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Jan 2015 01:24:51 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_E20C9A6B-2488-46B3-8AEB-F22E428782A8"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: 🔓Dan Wing <dwing@cisco.com>
In-Reply-To: <CAOW+2dvhEzAfyV51p1YWZoc41vih3TKhoArq3CGXzHvSdHEdcA@mail.gmail.com>
Date: Tue, 13 Jan 2015 17:24:51 -0800
Message-Id: <CE6C1F4D-FFA8-4ACA-8807-A624659AECC6@cisco.com>
References: <CAOW+2dvhEzAfyV51p1YWZoc41vih3TKhoArq3CGXzHvSdHEdcA@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/LUTp_S9ndsjwoXSVb0KKltI2gsI>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jan 2015 01:24:55 -0000

On Jan 13, 2015, at 4:48 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

> A question about negotiation of the use of the SRTP MKI field in DTLS/SRTP. 
> 
> RFC 5764 Section 4.1.3 has this to say about negotiation of support for the SRTP MKI field in SRTP/SRTCP: 
> 
> 4.1.3.  srtp_mki value
> 
>    The srtp_mki value MAY be used to indicate the capability and desire
>    to use the SRTP Master Key Identifier (MKI) field in the SRTP and
>    SRTCP packets.  The MKI field indicates to an SRTP receiver which key
>    was used to protect the packet that contains that field.
> 
> Looking at draft-ietf-rtcweb-rtp-usage, draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch, there is no additional mention of the SRTP MKI field.  
> 
> What can be concluded about negotiation and support for the SRTP MKI field within WebRTC implementations? 
> 
> Do existing WebRTC implementations have the capability to receive or send with the SRTP MKI field (e.g. if the peer implementation requests it?)
> 
> Do existing WebRTC implementations indicate a desire to use the SRTP MKI field? 
> 
> Does the IETF RTCWEB WG have any additional guidance to provide on this topic beyond what is in RFC 5764 Section 4.1.3?

The function of SRTP MKI overlaps with EKT (Encrypted Key Transport), and using both would significantly complicate EKT.  Thus, in EKT, we prohibit using MKI and EKT together.  EKT brings a lot of advantages to conferencing which cannot be achieved solely with MKI (no matter how MKI is signaled).  For WebRTC, I don't see SRTP MKI being used.

-d