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

Martin Thomson <martin.thomson@gmail.com> Wed, 14 January 2015 21:49 UTC

Return-Path: <martin.thomson@gmail.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 266F71ACD4A for <rtcweb@ietfa.amsl.com>; Wed, 14 Jan 2015 13:49:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] 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 JUKquMobSe9D for <rtcweb@ietfa.amsl.com>; Wed, 14 Jan 2015 13:49:55 -0800 (PST)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E03C1ACCEB for <rtcweb@ietf.org>; Wed, 14 Jan 2015 13:49:55 -0800 (PST)
Received: by mail-ob0-f177.google.com with SMTP id uy5so10107873obc.8 for <rtcweb@ietf.org>; Wed, 14 Jan 2015 13:49:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BvOrWAeNDAjKC05FLjQ5h4LRChBsL6tB7xGPaKfKI9c=; b=IPxiO030HOJHVT0Nvpn/xYNe86EXdTT5VeHnn9+sMKeY/JajKvnFGSCczFQx3N5MtV Z66tIP3mulR9VETD5OKfyXCKeHtODrOZo+WAaqhE+StYLPDwMgKi1M+qpFWJ3mDg4Ggk OXVpHreIqoHfK9c3F/lbB2OXInZI4/Nn9jZFo9fcWkFJycIYnU9pXXVqzPwQYRQkg41U oZuH4lFQ/ekntKF14VRaBUqtpe1NbgGk8/JqZpSC/mC+8/ansmaJYodnXJh1x1wjCP3W OncQsbq4Zm7vSUrMkaTfC6BIUajxIphyzBWWp4glHyhpZfB68PrwgwCsDAOFeVFiohse ZJNQ==
MIME-Version: 1.0
X-Received: by 10.182.58.102 with SMTP id p6mr3897870obq.84.1421272194546; Wed, 14 Jan 2015 13:49:54 -0800 (PST)
Received: by 10.202.226.136 with HTTP; Wed, 14 Jan 2015 13:49:54 -0800 (PST)
In-Reply-To: <CANO7kWC2G+r8jRmoPrYdMy0s+TiPuzy4TvgRSQ_QTyA3cW-njw@mail.gmail.com>
References: <CAOW+2dvhEzAfyV51p1YWZoc41vih3TKhoArq3CGXzHvSdHEdcA@mail.gmail.com> <CANO7kWBjs4AwyTXXhOBSDqG=y9ThM=XkLyO_S1xPe3naL9za_Q@mail.gmail.com> <CAOW+2dt5k+dbxRbdodu5Sh+t6zzX0bVgXBUMnmSe+kJP2R+LLw@mail.gmail.com> <CANO7kWATfQdMapdCSDYdke+GFxh8OO6NJQob9hNQUDiASrpDtQ@mail.gmail.com> <CABkgnnV-irZn9N7WMTbvn4Vm1Ltqc7tzoCJo3_towfa6PSRwPw@mail.gmail.com> <CANO7kWADQLXheo6mhgrEt-0XYwXHYbiq8=oOnOxOsqz4diw6nA@mail.gmail.com> <CABkgnnW4pxL+rqF41b==wqHjMEP_7bKs_jJ4SXgGbyMpPP_rQg@mail.gmail.com> <CANO7kWC2G+r8jRmoPrYdMy0s+TiPuzy4TvgRSQ_QTyA3cW-njw@mail.gmail.com>
Date: Wed, 14 Jan 2015 13:49:54 -0800
Message-ID: <CABkgnnWyHd=qwoY9SrAcYhydoaDSKfm3y5QN0vMYgRoD5+j=zg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Simon Perreault <sperreault@jive.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/lMIwv0ezdXNRZyv7zF9qBAlcd0k>
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 21:49:57 -0000

On 14 January 2015 at 11:37, Simon Perreault <sperreault@jive.com> wrote:
> use_srtp is in ClientHello, and that's renegotiation, right? If so, can you
> end up with new keys without a new MKI?

The use_srtp extension really only allows the peers to negotiate which
SRTP cipher they want to use, it doesn't really establish the keys.
That's the role of the exporter.

In theory, you could derive new SRTP keys without doing a
renegotiation, but we don't have a defined way of doing that.

SRTP is somewhat disconnected from the whole DTLS thing.  So I think
that the idea is that it continues with the old keys until it receives
some signal.  Either an MKI bump, or the sequence number discontinuity
thing Roman suggests using.  Either way, you need some signal *in
SRTP* that the keys have changed.

And then it's down to assumptions: assume that the DTLS master secret
has changed and re-export to get new traffic keys.  Of course, you
*really* need to check that the master secret has changed or you get
into trouble.