[rtcweb] Question about srtp_mki in DTLS/SRTP

Bernard Aboba <bernard.aboba@gmail.com> Wed, 14 January 2015 00:48 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 176691ACE21 for <rtcweb@ietfa.amsl.com>; Tue, 13 Jan 2015 16:48:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YsFTSn2uqZGN for <rtcweb@ietfa.amsl.com>; Tue, 13 Jan 2015 16:48:24 -0800 (PST)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC33D1ACE2A for <rtcweb@ietf.org>; Tue, 13 Jan 2015 16:48:23 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id k48so6014018wev.5 for <rtcweb@ietf.org>; Tue, 13 Jan 2015 16:48:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Yi0l7cGTm67MMCufcJG9eFoc7oQXNxf4tstJ1PGoIlw=; b=w3pBjEKmcjHd3iybcK3UAVHWeteUCkxCHtNxJ6oMRMKmSftxS4PPzNsJPwKdst4/nP mT89PoA4dgKTHCV9fcpHV6RaMBZU0KJAiFsUw3pUBtTyncU9cyfh04oSSMczBbC8vjmD Pi5Zpu5sivmdggzci4WVQAJnpQgkhYa3I5cKqaGtHjktN71Vh4glhaEGVkU7LULZjdMb gwcTfZWg4AF8dHcwOYh28fE1w4SGsN/52pRkFcRmLPeDCE1k9lOMlZhaEUnpRRrwRThC l7zTAB1/boJx3MeY9L5HS/xjoCr3fL27wTtLwNMm7NRHrr4vbOOvpQUHGWFAyuwDy7gx OSZQ==
X-Received: by with SMTP id dh6mr1813561wjc.87.1421196502657; Tue, 13 Jan 2015 16:48:22 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 13 Jan 2015 16:48:02 -0800 (PST)
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Tue, 13 Jan 2015 16:48:02 -0800
Message-ID: <CAOW+2dvhEzAfyV51p1YWZoc41vih3TKhoArq3CGXzHvSdHEdcA@mail.gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary=089e01419d80b27051050c921857
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/mgWTw9mpGz6sRTWpyjMgATRl7Vw>
Subject: [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 00:48:26 -0000

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

4.1.3 <https://tools.ietf.org/html/rfc5764#section-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

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?