IETF Logo Mail Archive

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

Simon Perreault <sperreault@jive.com> Wed, 14 January 2015 16:34 UTC

Return-Path: <sperreault@jive.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 C0F531A9024 for <rtcweb@ietfa.amsl.com>; Wed, 14 Jan 2015 08:34:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 NE1sbijZkX9t for <rtcweb@ietfa.amsl.com>; Wed, 14 Jan 2015 08:34:41 -0800 (PST)
Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349371A8FD2 for <rtcweb@ietf.org>; Wed, 14 Jan 2015 08:34:29 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id s18so9069287lam.2 for <rtcweb@ietf.org>; Wed, 14 Jan 2015 08:34:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jTga4mxQg4DRrEsDSRhXxoShiqdYsunzPIfztlDvMOo=; b=bjacw9B6nxdfA2Awgm0sxc5p9Jp8m0hjbhdWhXlvr9IedX9QHICpe6BPl34hnoagTA TM4u7xSKCwZ1n8ScSH7QLRwboHnyIU4pWcdIpKrzyWcjrRS/GjovP8OktU/+DvnartEe 94XzNSyEN6Gh3EXF0OQzXm1tGu5XZoEMYEyqxbEr3BVZzRxSfKh6weiJggskVFcY0D0h cK4fU8QClVJYxSsGEEjneUbGMIZwXqwXRmGfzIsL+KDyTSjD+8uR23LwaA3RbwyTMnnt Orf7cUWYdQnx4GMfWOgVvTLf9l/xVUBdiPfjXEcGp/3jgvRj+1y8F3lt2PdWvpvaVafu SwLw==
X-Gm-Message-State: ALoCoQn0nm1bEJeNEqnqzd1QFTDcycd/Od60TugugAhUqhEH3LYiia9UfvZ4Fy+aMewHFXVZ5ep2
MIME-Version: 1.0
X-Received: by 10.152.44.129 with SMTP id e1mr4894217lam.43.1421253267399; Wed, 14 Jan 2015 08:34:27 -0800 (PST)
Received: by 10.25.84.145 with HTTP; Wed, 14 Jan 2015 08:34:27 -0800 (PST)
In-Reply-To: <CAOW+2dt5k+dbxRbdodu5Sh+t6zzX0bVgXBUMnmSe+kJP2R+LLw@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>
Date: Wed, 14 Jan 2015 11:34:27 -0500
Message-ID: <CANO7kWATfQdMapdCSDYdke+GFxh8OO6NJQob9hNQUDiASrpDtQ@mail.gmail.com>
From: Simon Perreault <sperreault@jive.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
Content-Type: multipart/alternative; boundary="089e0160bc3823be66050c9f502d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/0Xx2rDoUsiqsX77jHSn538E2AQA>
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 16:34:56 -0000

On Wed, Jan 14, 2015 at 11:08 AM, Bernard Aboba <bernard.aboba@gmail.com>
wrote:

> "I would much prefer to use MKI because otherwise re-handshake is very
> complex and brittle. I did implement re-handshake, which is uncommon."
>
> [BA] Can you describe the scenario for DTLS re-handshake?
>

Sure. It is described in detail here:
https://tools.ietf.org/html/rfc5764#section-5.2

Basically when a re-handshake happens you have to keep old keys around for
120 seconds in case old SRTP packets are still traveling the internet and
have yet to arrive.

Without an MKI, when packets arrive you have to try to authenticate them
with the newest key, and if that doesn't work try progressively older keys.
It's a hassle: you have to store keys in chronological order and iterate.

With an MKI in the packet there's no iteration: you know exactly which key
to use. You just grab it from the key table which you index by MKI.

Simon

v2.23.0 | Report a Bug | By Email