Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

Alan Johnston <alan.b.johnston@gmail.com> Fri, 26 April 2013 16:53 UTC

Return-Path: <alan.b.johnston@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D0F21F9927 for <rtcweb@ietfa.amsl.com>; Fri, 26 Apr 2013 09:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.933
X-Spam-Level:
X-Spam-Status: No, score=-100.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qULIVZ5tA+L for <rtcweb@ietfa.amsl.com>; Fri, 26 Apr 2013 09:53:37 -0700 (PDT)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67E21F991F for <rtcweb@ietf.org>; Fri, 26 Apr 2013 09:53:31 -0700 (PDT)
Received: by mail-wg0-f46.google.com with SMTP id e11so2247470wgh.13 for <rtcweb@ietf.org>; Fri, 26 Apr 2013 09:53:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mE4Zqlmh9YgdFZt9sSfsppHhbzvdZqgIDT0OG4p4w38=; b=aW/+7aEp0YH4wxi4aqiSsKJVkz1Zru5moSWvAheGEsHFjTB/kFSd61+JQYqtJt4cOH gJEqRzyGKp0tOBAbrGqk3/enHsp7Czg7DVpn8fVVja0O92GJlj6TPNI50QyG4lHqBk/r N1kF+xd28rN2HBv1BZMZaxxdmsijPcklUk65MIk0s/uqX0BDUSvOWipG3usSaIcKBeHx 2tzaONvvwFsiOPkCuEI1+Vw/bohpUOxz03OSr7eds62+r87znst6BYjCivL2wckrYSYl GjWWb96lZXWCaw8cASceYYskJPmGb1oRotX7auU9d9KZr77HU4GrF1GQ01BMVf2mwmUv g0eg==
MIME-Version: 1.0
X-Received: by 10.194.122.7 with SMTP id lo7mr61588500wjb.48.1366995211222; Fri, 26 Apr 2013 09:53:31 -0700 (PDT)
Received: by 10.216.173.134 with HTTP; Fri, 26 Apr 2013 09:53:30 -0700 (PDT)
In-Reply-To: <5179AC21.5060708@nostrum.com>
References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <20130425202238.74EF321F96A5@ietfa.amsl.com> <AE1A6B5FD507DC4FB3C5166F3A05A48416281FDB@tk5ex14mbxc272.redmond.corp.microsoft.com> <03FBA798AC24E3498B74F47FD082A92F3BB8FAF7@US70UWXCHMBA04.zam.alcatel-lucent.com> <CABkgnnWQZ+5aP0pQRB5Wx9v7pViw4dtd2Hrz6Zwn2XooSkwtvA@mail.gmail.com> <5179AC21.5060708@nostrum.com>
Date: Fri, 26 Apr 2013 11:53:30 -0500
Message-ID: <CAKhHsXGk_5Es5CFtA49Hk5r_W94uMFCoUP4TYjJUXYoY4Mhbhw@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: Adam Roach <adam@nostrum.com>
Content-Type: multipart/alternative; boundary="089e0115ee76f9858404db465f40"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 26 Apr 2013 16:53:40 -0000

What about the API considerations?

If two browsers have a source of keying material, such as a preshared key,
or material derived from something else (i.e. keys on flash drives), the
API needs to be able to give this key to the browser to use.  This API
issue is orthogonal to whether the key has been shared over an insecure
signaling channel or not.

- Alan -


On Thu, Apr 25, 2013 at 5:20 PM, Adam Roach <adam@nostrum.com> wrote:

> On 4/25/13 17:11, Martin Thomson wrote:
>
>> Data channels can continue to use DTLS even though media is encrypted
>> using keys provided by security descriptions.
>>
>
> The arguments for SDES fall into two categories, AFAICT: (1) Those
> required for interop with legacy devices, and (2) those which we are
> prohibited by RFC 2804 from considering. And there is no possible way
> DataChannels are going to interop with legacy devices.
>
> I agree with Alan that we shouldn't make accommodations to use SDES for
> the brower-to-browser case. By implication, this means that the presence of
> DataChannels necessarily means that we're using DTLS-SRTP for the whole
> session. Given those assumptions, the mixed-session scenario you describe
> does not arise.
>
> /a
>
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>