IETF Logo Mail Archive

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

Eric Rescorla <ekr@rtfm.com> Tue, 30 April 2013 18:53 UTC

Return-Path: <ekr@rtfm.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 55D3421F9C5D for <rtcweb@ietfa.amsl.com>; Tue, 30 Apr 2013 11:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.425
X-Spam-Level:
X-Spam-Status: No, score=-100.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 xksDVVnH5LTY for <rtcweb@ietfa.amsl.com>; Tue, 30 Apr 2013 11:53:01 -0700 (PDT)
Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2190F21F9A86 for <rtcweb@ietf.org>; Tue, 30 Apr 2013 11:53:01 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id b25so380910qca.17 for <rtcweb@ietf.org>; Tue, 30 Apr 2013 11:52:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=1ykk5eSA3IyYEFjTNC6pwWRj7F5r6NCFC0dsLUYgLmk=; b=el0phXgE6fHAxBPz23HeYB3m14ozylEsMd8H2TUdJKS82uSddL8s1mRsz/v1/Rav+j S3WYcAyQfaKOs9X6h3yP6wJaXVM9DQOY6pLOgFzZVT7ve+vapNXz55D1s/vxCoCCWzMM MXHt2HamL3PxQXkYNE7BxKywvB97Wei6AqP+H6dcyHGXAU9/T6ckACeHpnQdhqRgCkw9 EL0yFA9UQ/Lbeh2pq7VfTWAEIyS9QSVP342OU2XB7TrkqorBx+rGvfk3exMSDATSoZrp Dl+BazF7gP5nhq3GG8sLrsLXzIfiqPqqy2rqsmf6OVLNHCleIlYhofEhGoDZ7CwODt76 aCzw==
X-Received: by 10.49.3.6 with SMTP id 6mr40135818qey.64.1367347979296; Tue, 30 Apr 2013 11:52:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.17.66 with HTTP; Tue, 30 Apr 2013 11:52:19 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3BB9D535@US70UWXCHMBA05.zam.alcatel-lucent.com>
References: <BLU402-EAS17255F45B0904B070F0D43093B00@phx.gbl> <03FBA798AC24E3498B74F47FD082A92F3BB9C0F6@US70UWXCHMBA05.zam.alcatel-lucent.com> <517F658E.8010204@ericsson.com> <03FBA798AC24E3498B74F47FD082A92F3BB9D535@US70UWXCHMBA05.zam.alcatel-lucent.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 30 Apr 2013 11:52:19 -0700
Message-ID: <CABcZeBMJvrERsYG8jnYT1tOunvHhmLvQAvL4qsSP8Ei8VuZ3BQ@mail.gmail.com>
To: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="047d7bdc0aba97331104db98822d"
X-Gm-Message-State: ALoCoQk2z4IMzmXA3qV4aNkdSj8uzQbIVFlGbiFCMQMQrNIrsO5GmfEdrs9O/Q75xy7iw7O1lhaN
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: Tue, 30 Apr 2013 18:53:06 -0000

On Tue, Apr 30, 2013 at 8:14 AM, Ejzak, Richard P (Richard) <
richard.ejzak@alcatel-lucent.com> wrote:

>  Hi Salvatore,****
>
> “are you proposing that when/if we will eventually use SDES we have to
> assure that the key exchanged
> is the same key used by the DTLS session, on top of which runs Datachannel?”
> is a reasonable interpretation of what I am proposing, although I would
> have described this as my “preference” rather than a concrete proposal.  We
> could mix SDES for voice/video with DTLS for DataChannels in these
> scenarios, but an all-SDES approach (for keying) would be more efficient.*
> ***
>
> ** **
>
> I know that this option is not currently defined, although it does seem
> technically feasible (which is why I asked to ekr to comment).
>

I don't think this is really practical. It would require defining a new
crypto protocol
to carry the SCTP.

-Ekr

v2.23.0 | Report a Bug | By Email