[rtcweb] DTLS, DTLS-SRTP, and 5-tuples

Simon Perreault <sperreault@jive.com> Wed, 04 March 2015 18:12 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 D79E31A9308 for <rtcweb@ietfa.amsl.com>; Wed, 4 Mar 2015 10:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jvmn5-VQUFtx for <rtcweb@ietfa.amsl.com>; Wed, 4 Mar 2015 10:12:21 -0800 (PST)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6361A9302 for <rtcweb@ietf.org>; Wed, 4 Mar 2015 10:12:21 -0800 (PST)
Received: by qcyl6 with SMTP id l6so38915426qcy.2 for <rtcweb@ietf.org>; Wed, 04 Mar 2015 10:12:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ZfnwfHaX+cVp2D+iKqcquTtCGk8wbKZU54Tp0r7yzSs=; b=loO5GfPA/EJD/rtzVAAs60zGd8kanZ7wsXJ1anTTRSWpb6LlscD5x+kDtG4ko2dKut Q4Ys4fG0RUUiT9oV1gLVvN5blYS8CItTmIwoRbn1eFQkONKf2MPylGZlqTZSz6SwGskl lbJOoXNVUUqBl4XFyAxqtvXCOsuuQHwNsETQl4vC8sY/u9IyiERGaICugtsvwk1jax5E vD4Qn2fJ1FIguZRgWSe+QFNRofzAs9g6DNCm0DkTJ+VXlwfVyJ/FoPvSiKq8YCf7fIoK BA7I3/PnUvZHLMafRyfNT0nJP1rSPrYiuyyMvcmCHTt6SIwSuq6oareO5BO9u08lCM7A DQYQ==
X-Gm-Message-State: ALoCoQmKCrORdlxYuH82rogRTSeTFpUYVGzFt9iJ5joIgPk+byjS3VbtliGZ3PgdnrTB7oGD/o8b
X-Received: by 10.140.33.164 with SMTP id j33mr7362589qgj.10.1425492740587; Wed, 04 Mar 2015 10:12:20 -0800 (PST)
Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id 86sm1464635qkw.13.2015.03.04.10.12.19 for <rtcweb@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 10:12:19 -0800 (PST)
Message-ID: <54F74B02.1070902@jive.com>
Date: Wed, 04 Mar 2015 13:12:18 -0500
From: Simon Perreault <sperreault@jive.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/AwylSNB33qRdmSc_ZYyXliGA0CI>
Subject: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples
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, 04 Mar 2015 18:12:23 -0000

This is a follow-up to this thread on discuss-webrtc:
https://groups.google.com/forum/#!topic/discuss-webrtc/i67xq-FWtoM

I see two distinct problems:

1. It must be possible for a DTLS connection to jump from one ICE 
candidate to another. That is, a DTLS connection must not be bound to a 
single 5-tuple. This can be deduced from a good understanding of ICE, 
but it could certainly be stated more clearly.

2. SRTP keying material extracted from a DTLS connection must also not 
be bound to a single 5-tuple, in case media jumps from one ICE candidate 
to another. That's more problematic because RFC 5764 states very clearly 
that keying material is to be bound to the DTLS 5-tuple, modulo forking.

If I'm not mistaken, the right thing to do would be to bind keying 
material to all local ICE candidates (multiple 3-tuples), and treat any 
incoming media flow as indicated in RFC 5764 page 15, with one mapping 
table per 3-tuple. For outgoing flows, I guess it would make most sense 
to bind keying material to the 5-tuples for which the sender has 
obtained consent.

Is this correct? If so, would it be useful to add text explaining this 
in detail?

Simon