Re: [rtcweb] No Interim on SDES at this juncture

"Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net> Tue, 18 June 2013 19:02 UTC

Return-Path: <matthew.kaufman@skype.net>
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 8FE2311E80FC for <rtcweb@ietfa.amsl.com>; Tue, 18 Jun 2013 12:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599]
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 6Y2YZehfKj6u for <rtcweb@ietfa.amsl.com>; Tue, 18 Jun 2013 12:02:50 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9205111E80F7 for <rtcweb@ietf.org>; Tue, 18 Jun 2013 12:02:44 -0700 (PDT)
Received: from BL2FFO11FD009.protection.gbl (10.173.161.201) by BL2FFO11HUB009.protection.gbl (10.173.161.111) with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 18 Jun 2013 19:02:41 +0000
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 18 Jun 2013 19:02:41 +0000
Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0136.001; Tue, 18 Jun 2013 19:02:23 +0000
From: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Hadriel Kaplan <hadriel.kaplan@oracle.com>
Thread-Topic: [rtcweb] No Interim on SDES at this juncture
Thread-Index: AQHOZrw6CQcaVcHO7ESUEcTH2Hsm5ZkxWrGAgADdvYCAAA4GAIACkewAgACbDYCABdNvAIAAlhWI
Date: Tue, 18 Jun 2013 19:02:22 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A4841A2C78AD@TK5EX14MBXC273.redmond.corp.microsoft.com>
References: <CA+9kkMDnjCNXGV0GU7x6gbbZMf4WiEuVvCRY8_Fix5tmdOB-Kg@mail.gmail.com> <AD220324-EEE7-4800-8512-FD7BADA9EC34@oracle.com> <CA+9kkMDY2Z_5_1uYJ1K_ZmrJB2a1-RE7V3aPqNHQg82DyagjCg@mail.gmail.com> <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com>, <51C02EE8.5070809@ericsson.com>
In-Reply-To: <51C02EE8.5070809@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.33]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454002)(189002)(51704005)(199002)(24454002)(52314003)(377424003)(77982001)(79102001)(31966008)(66066001)(74876001)(81542001)(80022001)(561944002)(23756003)(69226001)(46102001)(33656001)(74366001)(44976003)(76786001)(81342001)(54316002)(6806003)(76482001)(56816003)(47776003)(54356001)(76796001)(50466002)(20776003)(55846006)(77096001)(53806001)(59766001)(74706001)(63696002)(56776001)(65816001)(47736001)(49866001)(4396001)(51856001)(47446002)(15202345002)(74502001)(47976001)(74662001)(50986001)(16406001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB009; H:TK5EX14MLTC104.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0881A7A935
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] No Interim on SDES at this juncture
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, 18 Jun 2013 19:02:55 -0000

Back on April 25th, I made some claims. I still believe these are true:

1. DTLS-SRTP w/EKT is exactly as secure as SDES sent over HTTPS... it is just a different encrypted channel over which the key is set.

2. DTLS-SRTP w/EKT requires a more complex media gateway relationship for interworking (as it needs to be in-path for the keying on that side, despite the use of SDES on the other side).

3. DTLS-SRTP w/EKT for interworking exposes the key via SDES on the other side of the interworking relationship anyway, so even though there isn't SDES to the browser there's SDES on the other (likely SIP) side.

4. And DTLS-SRTP without EKT fails completely for the cases where the key needs to be set for interworking.

5. And finally, to get the browser-to-browser security guarantees you would need to be A) sure that you're really talking browser to browser and not via something else in path (like a mixer) and B) would really prefer that there be no way that the in-path device be able to force a key (thus you'd want to NOT allow EKT in the browser-to-browser case, even though there's no way for a browser to know for sure what it is talking to... I suppose that *if* you trusted your browser and the browser at the other end (which you need to do anyway, because they could just leak keys or media), you could mandate that browsers set some bit that disallows EKT and hope that the other end respects it)


Since we can't get interworking at all without either DTLS-SRTP + EKT or SDES, and since the security guarantees of DTLS-SRTP + EKT are the same as those of SDES, and since the interworking gateway is made more complex (because the keying must be in-path), I believe the only possible conclusions are A) We accept that interworking with other SRTP systems is desirable and therefore SDES is the best way to achieve that or B) We prevent any interworking with other RTP or SRTP systems.

As someone who could make some money sending traffic to/from non-RTCWEB networks, I'm a fan of "A".

And no, I'm not planning on writing a draft that says to just do what we should be doing anyway.

Matthew Kaufman


________________________________________
From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Magnus Westerlund [magnus.westerlund@ericsson.com]
Sent: Tuesday, June 18, 2013 2:56 AM
To: Hadriel Kaplan
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] No Interim on SDES at this juncture

Hadirel and WG,

Please see my response inline.

On 2013-06-14 18:58, Hadriel Kaplan wrote:
> You can't be serious. There was exactly ONE email asking for agenda
> items, here:
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07668.html It
> was sent on May 30th.  It gave a generous 6 days to respond.  Luckily
> no one ever goes on vacation for longer than 5 days. Instead, two
> people sent a response on June 10th, a tremendous 11 days after the
> request.  Outrageous!  That's a almost twice as long as they were
> given!
>
> Thank goodness the chairs detected this monstrous breach of
> procedure, and thwarted the attempts of anarchy!  I mean if people
> are allowed to respond to emails so tardily, how can we be expected
> to get things accomplished as quickly as they've so far been in this
> WG?!?

Yes, we have only sent a single email this time, being the second round
in a short time we tried to schedule this meeting.

>
> Sure, an interim for this topic has been waiting for many months if
> not a whole year, and now that people didn't respond in 6 days but
> took instead 11 days the topic will be delayed indefinitely yet
> again... but that's no excuse for blatantly flaunting the rules!

Yes, there has been difficult finding a time could work for this
meeting. That was why the agenda request time was short.

>
> Personally I saw the email on May 30th, and assumed Oscar and Dan
> would respond to you for agenda time.  I assumed that if no one had
> submitted agenda items to you, that the WG Chairs would send out an
> email warning about that, or perhaps even directly email the people
> who they expected to submit agenda items.
>

Yes, you assumed that someone would respond. Rather than you reaching
out to verify that others would drive the question for you. Hadriel you
are apparently very interested in this topic. Why don't you ensure that
an agenda topic is on the agenda for Berlin? The WG chairs are happy to
receive agenda requests already now.

>
>> If you want to discuss this, write a draft describing how how your
>> additional keying is to be integrated, what the pro and cons of it.
>> That will enable direct discussion of a proposal. The WG clearly
>> are opinionated on this matter, but apparently don't have energy to
>> produce proposals.
>
> There *are* drafts.
> http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00
> http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01 There
> are even powerpoint slides, sent to the chairs the last time this
> meeting almost happened but didn't.

One of those drafts has been expired since February I would like to
point out.

The looking at these drafts, they are neither a proposal for what to
actually do. Dan Wing's draft is argument in general why SDES would be
bad for security. Oscar Ohlsson's is an argument for why a number of
potential risks are not a serious issue and what the other gains of
using security descriptions are.

>From my perspective I really would like to see some progress in at least
the proposal for actually adding additional keying to ensure that the
raised issues in drafts or earlier WG meetings and email discussions are
meet. Additionally I would really like to see some more details for how
the actual integration of an additional keying mechanism is supposed to
work.


>
> I think the problem must be that those things weren't signed in
> triplicate, sent in, sent back, queried, lost, found, subjected to
> public enquiry, lost again, and finally buried in soft peat for three
> months and recycled as firelighters.

No, that is not it. This topic has dragged on for various reasons. Yes
we chairs are clearly to blame for some of them, like being slow to
attempt to schedule a meeting. However, after that there has been issues
finding a suitable time where sufficient mass of people could
participate. There has been time conflicts with other meetings resulting
in a cancellation, which in hind sight was unnecessary. Then a
rescheduling, lurk warm response from the WG, limited agenda items and
another almost collision resulting another cancellation.

I am sorry that this makes you frustrated. Well, it makes also me
frustrated. I wished this topic was dealt with and out of the way, but
it is not. So, if you want it dealt with. Please request agenda time for
Berlin and ensure to update any drafts or other material to actually
take into account what actually has happened in the last 15 months.

Regards

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb