[rtcweb] Draft Minutes from RTCWEB day 1, Aug 1 2013 Berlin IETF 87

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Thu, 22 August 2013 18:10 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 40FFE11E812A for <rtcweb@ietfa.amsl.com>; Thu, 22 Aug 2013 11:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.522
X-Spam-Status: No, score=-109.522 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1XayhbmjaFJE for <rtcweb@ietfa.amsl.com>; Thu, 22 Aug 2013 11:10:25 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id CDCFD11E811B for <rtcweb@ietf.org>; Thu, 22 Aug 2013 11:10:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43785; q=dns/txt; s=iport; t=1377195024; x=1378404624; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=msg1QnosgAb+lCvVkFGBNICP/pq+/eYIr/KnxV+WZbg=; b=iAggcCPgNBPXNF+46hPqr0lUEfT7zU+LZwhm0rwRXPb0Dtqcg2Pq0ojr R/LQRPRGHNgBeY8bG7JMNhQnMHasHOV+NJ9KotxaRNvWwIrFQYLuat+yy 00MiR1r6QIOU86HyNnt09XuFobJD9rbLwV83zPcKx5YZXY4cxEQYN2FZ/ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AowFAF1TFlKtJV2a/2dsb2JhbABEDAEJgweBBsAIgR0WbQeCJgEEGgEfLgQDBxUBGhALCUIXEAQbE4d1lTmhO48WBwYBgRFCgxF7A6lAgx+BaQUEFyI
X-IronPort-AV: E=Sophos;i="4.89,935,1367971200"; d="scan'208";a="250581403"
Received: from rcdn-core-3.cisco.com ([]) by rcdn-iport-8.cisco.com with ESMTP; 22 Aug 2013 18:10:23 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com []) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7MIANif005463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <rtcweb@ietf.org>; Thu, 22 Aug 2013 18:10:23 GMT
Received: from xmb-aln-x02.cisco.com ([]) by xhc-aln-x07.cisco.com ([]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 13:10:23 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Draft Minutes from RTCWEB day 1, Aug 1 2013 Berlin IETF 87
Thread-Index: AQHOn2LeVLoWPzCRDUmFTT6BIrXUbA==
Date: Thu, 22 Aug 2013 18:10:22 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB114920202@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E81E381CB945534094A2A9097D2DED6F@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [rtcweb] Draft Minutes from RTCWEB day 1, Aug 1 2013 Berlin IETF 87
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: Thu, 22 Aug 2013 18:10:31 -0000

We're splitting up the minutes review for the two different days of the last IETF meeting.  Please review and send corrections to the list.


Draft Minutes from RTCWEB session 1, Aug 1 2013 Berlin IETF 87


The meeting decided that the WG guidance would be that browsers MUST NOT support SDES. Note this does not change the previous decision that browsers MUST support DTLS-SRTP. 

Expect an update of  the JSEP draft around Sept 15.

Thank you for minutes to Jon Peterson and Ben Campbell for taking minutes.  

Raw Notes Bellow. 

Ted: intro

Ted: noting that we need to follow the recent consensus of MMUSIC on bundle



H has a joke - support legacy currency DM vs EU

H sets out arguing for SDES for MTI - noting DTLS-SRTP is already MTI, but will only be used "much of the time" - can the browser support SDES in the API known as SDP 

H has another joke - E Berlin is RTCWeb, W Berlin is SIP

H argues that SIP gives you the latitude to choose your own security solution. Argues SDES reduces media clipping because it negotiates faster. Skeptical of e2e SIP-RTCWeb deployment, due to RTCWeb features, and thus you could do do different things on different sides of a gateway. SDES "trivial to implement," widely implemented.

Notes that for eavesdropping, interworking gateways do indeed see and log keys. Argues there's little to be done to defeat NSA or similar adversaries. DTLS-SRTP has the same properties.

Regarding PFS, DTLS-SRTP has similar properties he argues as SDES as well.

On downgrade, "if you're talking to a malicious web server, you're doomed." Evil web server can insert itself as a DTLS-SRTP MITM as well.

Argues that DTLS-SRTP is also verifiably secure e2e - in part due to lack of IdP, and even with IdP, you only know up to the endpoint, not beyond. SDES is thus perhaps more honest, because there's no such guarantee in place. 

If we're wrong, we can remove and deprecate SDES. Web browsers upgrade very, very fast if we need to back something out. However, even if we update browsers, the services don't have the same agility. 

What do operators care about? Argues that native apps are more important than browsers for this, that people won't spawn a browser to receive calls. He suggests native apps based on a web framework as a compromise to support SDES, to interop with existing VoIP devices, prevent clipping and reduce overhead.


M is wearing "Comment 22" jacket, receives much laughs

M speaking in favor of SDES, even though in an ideal world he'd rather use DTLS-SRTP. His app needs SDES.

M shows ICE use cases that can't support DTLS-SRTP.  Various intermediaries and conference scenarios. For example, crypto overload with an audio mixer on a conference box, For many of these cases, either SDES or EKT will work though. Notes that EKT is current undeployed and unrealistic,

Would rather not have crypto in his app for plausible deniability, would rather just forward packets as a service. No keys and media in the same place = good (maybe).

M somewhat hedges on the early media clipping - different modes have different results.

Shows some good reasons to use DTLS-SRTP, but notes however that they haven't been so successful in SIP deployments. Shows what will happen if we deploy IdPs and what the benefits would be, and at what cost. If any piece of the puzzling is missing, then you end up with about the same properties as SDES. How can we guarantee all of the steps needed for DTLS-SRTP to be secure will prevail in practice? Credential management a big question here.


(wrong presentation is put up on screen, bad chairs no cookie)

E believes everyone agrees on the facts - in SDES, server has access to the keys, and thus with passive access to the media, they can recover the content. E says not so with DTLS-SRTP, they can only launch an MITM attack. With IdP, you can detect attack by signaling server.

Shows a gmail slide for auditing your connection history, to suggest that you could do the same for RTCWeb.

Note that the passive attack enabled by SDES can be mounted retrospectively, based on captured media and logs. Speaks anecdotally to recent legal concepts of interception. SDES attack is impossible to detect, because its passive, but he argues that there's in principle ways to detect server attacks with DTLS-SRTP, though not easy. Easy to "accidentally" mount a passive attack due to incompetence, active attacks not 

Argues that the performance numbers are not as bad as people are representing - in computation or in network transit time. Argues that clipping is a non-issue, there could be 1 RTT of difference but no more, especially compared to the ICE overhead. Alludes to a new mode of DTLS-SRTP with less latency for people you've talked to before, new work in TLS WG. Argues post-dial delay is much longer for other reasons.

Backwards compatibility - notes that the vast majority of RTP traffic isn't SRTP, so backwards compatibly already has to bite that bullet - need a gateway.

Is re-encryption a big deal? At a gateway or a conference bridge or what have you? Codecs unsupported in the native SIP world anyway, so you need some kind of transcoding. Number of extent RTCWeb MCUs low enough that we could get EKT done in time for then, he argues.

E argues that everyone agrees DTLS-SRTP is better, and if we don't prevent SDES, people will use. Don't give them a "foot gun" to shoot themselves in the foot. Incompetence is the first problem.

Malice is the second problem, E says. There will be a trivial bid down. Can't distinguish people trying to monitor you from the people who are just lazy.

E wonders if people will inspect the JS to see what's going on. Talks about recent surveillance disclosures and the way that SDES would enable these passive, historical attacks.

E summarizes that DTLS is either somewhat better or a whole lot better. Legacy systems where SDES makes things "somewhat" easier will only get more rare and better performing as time goes on. 

E argues that browsers MUST NOT implement SDES - however caveats that gateways do SDES.

EKR concludes.

Cullen asks for clarifying questions first on the presentations, factual challenges etc.

Ted asks that we focus on the question "what role (if any) should SDES play in RTCWeb"? Don't get caught up in nits.

H opens with a joke (JYIS). Says that if the JS has access to the raw media, thus you are screwed.  Asks if multiple calls to the same person going through different gateways would throw a sec exception.

E responds "nah".

H says DTLS-SRTP doesn't give you the property of knowing you're talking to the same person with IdP.

M says the performance argument is a straw man. Unclear what he thinks the performance analysis should be. Agrees with Langley's analysis. Agrees cost isn't much in terms of CPU usage, that it's irrelevant. 

Dan Druta - says presos has misleading information about what browsers are. Distinguishes between  browser and a runtime. Is it a web runtime or not? (Ted asks for clarification) Druta says W3C looks at a different set of use cases for web-based OSs, and that we should remember the distinction.

Justin Uberti -  Notes relative maturity of the two different approaches. Bizarre bug reports about people who can't get DTLS-SRTP to work. Presumption to say that DTLS-SRTP is just "better." For some it will mean more work. Consider chromecast or similar non person-to-person communications. ("what?" from the crowd). Argues DTLS-SRTP not mature.

Bernard Aboba - Doesn't buy clipping at all. Will clip in both scenarios. Difference unimportant. Performance arguments also irrelevant, except the large conference case. Can't evaluate SDES alone for that without considering EKT. Wants to make the EKT decision before we rule for or against SDES.

Richard Ejzak - Not buying passive attack scenario. Says you need to break link-layer TLS to discover the keys - shouted down by the room, asked to take it offline.

Moe (?) - Threat analysis needed to distinguish EKT from SDES in this context. E asks to respond. E says the threat properties of EKT are substantially better. Need to control the endpoint to use EKT, so can't be launched by the server. Moe replies SDES folks would be happier if there was more of a story about large conf servers in terms of computational complexity. 1000 DH / millisecond.

Steve Kent - Presos and mic seemed to say the significant issue is security, not performance. Argues E's sec analysis is much better, that passive attacks are much much easier.

Joe Hildebrand - Argues he has large conf server application, WebEx. Needs access to plaintext for mixing, so needs to do the crypto ops. Doesn't care if it's a little computationally expensive, his hardware is cheap. Would rather have less ways of doing things, more complexity etc is a concern for him much larger than performance. DTLS is fine for him, and he interoperates with a lot of Cisco phones.

(missed name) - This would be a lot easier if we had perfect foreknowledge. Says that because RTP is basically unencrypted today, we can use that to predict that SDES would be used if allowed for RTCWeb. SDES a "moral hazard", easy to get out and get working. Don't allow it. EKT will cover places where people say SDES is needed today. Preserves intention for making SRTP mandatory.

(Ted says be brief)

H - Agrees with previous speaker. Marketing issue, even. For browsers, we should mandate DTLS-SRTP - just not for native apps that use a web framework. Argues that performance problems are real, and that clipping is real. (crowd grumbles) Hadriel says security is "fud bullshit" but that we should make a decision today.

Hannes Tschofenig - Surprised by cynicism of discussion. Concerned about global surveillance. "My view is no SDES."

M - Some FUD in both directions. Malice v. incompetence. Says that the APIs themselves have to do the work to get the properties we're talking about. The incompetence line of reasoning is thus specious. If people are gatewaying, you have to trust the site anyway. Requires competence on web developer part.

E - reference Plato. Question of developer incompetence. Talks again about what the passive attack is that incompetence at the server enables. Concerned about clipping. Addresses wide range of issues: PFS, the nature of the Moz stack, etc.

Relaying jabber room - Someone says they disagree with Justin - hard part was SDP, not DTLS.

Jeremy Fuller - People "want the best," invokes the IPv6 example of something that gets rammed down your throat by a standards body. Suggests users should have a choice between what standards bodies wish was real, versus what is actually real. Who here is using secure tunneling to browse the web? (many hands go up, and laughs) Argues to give users a choice.

Sam Hartman - familiar with SIP, understands issues. When you use DTLS-SRTP and mandate it, but don't permit SDES, you increase the work of a passive adversary. Even if developers are incompetent, etc, even if we're not using an IdP, etc, this will help. Sure, adversaries could recover keys form logging gateways, etc, but in other cases it causes adversaries to do more work. Don't support SDES, not for browsers.

Justin Uberti - Chrome can show DTLS is actually being used. Says they wouldn't give the same indication for SDES. Sees no security distinction between web browsers and runtimes. Calls RTCweb a "byzantine cathedral". EKT won't save us, though, he says.

Dan Wing - Status of EKT. "not updated for a while". Why did Cisco build EKT? For telepresence. This has a similar problem, don't want to do crypto in the MCU. They don't. EKT makes this work, with DTLS-SRTP. He is a co-author of SDES, and says, "please don't use it." We need DTLS-SRTP.

Alissa Cooper - On paranoia. There is a norm, and clearly this norm is violated for voice calling if you can passively attack media, and give a secure indication. Needs a 

(Kariani? Verizon) - Looking at mobile cases with RTCWeb and "standard" clients at once. Concerned about interworking between DTLS and SDES. Need to take some action to take mobile devices into account with "managed secure access." Doesn't want gateways long term.

(me at mic - no on SDES)

Hadriel - we don't have protection from collecting the media when there's gatewaying going on, "emperor has no clothes." We can't have a flag or something for SDES that users can "turn off" or what have you. If you control the app yourself, then you have more powers. But for RTCWeb, stick with DTLS-SRTP.

Sean Turner-  speaking as Sec AD. Wants to pick one. He doesn't want the best, wants better. Threatens discusses, given that Dan Wing disowns this and the passive attacker properties. "We're watching!" (laughs from crowd at irony)

(Roberto? missed name) - people choose convenience over everything else. if you give them choice, it's a choice between convenience and something else, and people will never choose something else. Pick security every time.

Russ Housley - Appalled by "k=" in SDP back in 2003. Violates principle of least privilege.  Let's not do it again.

(Matt?) - Says that in enterprise there are huge numbers of SDES devices out there, concerned about backwards compatibility. Doesn't want MUST NOT use SDES, but won't argue for MUST use it.

E - To Hadriel's point, gateways are not the only use case. RTCWeb is not always intermediated. If anyone doing Web-to-web calling can ever get anything other than DTLS-SRTP, that's unacceptable. Only way to prevent it is to ban SDES.

Wendy Selzer - Also concerned about passive attackers, says lets give end users the tools to prevent this form the start. 

(Ted recuses himself)

Cullen begins to take hums. Does the decision apply to web browsers, runtimes, native apps, etc. This WG is scoped around the input to webrtc in the w3c - thus applies to browsers and other entities that use the same technology. This is not saying that SIP phones can't use SDES anymore. Not at a point today to make a decision about EKT.  

E clarifies - document already says you MUST implement DTLS-SRTP, this is about adding SDES as an option.

First hum: On SDES: should our spec say we MUST implement SDES?

(no one in room) - one hum in jabber

Second hum: Or, you MAY?

(good hum)

Third hum: Or, you MUST NOT?

(better hum)

Substantially more support for MUST NOT than MAY

Same as on jabber

"A decision has been made."

H asks "a MAY for native apps" - did the hum preclude it? H presses point, Cullen says the distinction isn't meaningful in the IETF. "The only purpose of this document is a piece of advice to a W3C document."

<> MMUSIC Unified Plan - RTCWeb implications

Adam: Shanghai'd to give this presentation

Adam starts reviewing the existing drafts and deliverables

Keith Drage: what here is RTCWeb WG specific? what's to understand the inter-group process

M - MMUSIC can make the choice to scope any of their deliverables to RTCWeb.

Harald Alverstrand - RTCWeb shouldn't care what other uses other WGs will make of tech, just that they make it. Should parts of architecture go into overview doc? 

Cullen - Intro?

A - Mechanics of which doc it goes into is not the real question.

M - Wants more detail. What's "JSEP updates"?

A - Justin suggested it

Justin - described bunch of things that need to go into SDP when a stream is added. what happens when createOffer() is called? was depending on unified plan, need to get some text in there to reflect it.

Christer Holmberg - is partial offer/answer going into JSEP, or through some other browser mechanism?

Justin - through JSEP. Type of session description would be "partial offer".

Christer - is this an update to RFC3264? Will JSEP still be a 3264 update?

A - this doesn't change 3264 semantics

Christer - JSEP based on 3264, but not is 3264 plus partial O/A

A - partial O/A is MMUSIC

Justin - JSEP already divergent from 3264

Ted - when can we get some updates to reflect unified plan?

Harald - Sep 1 (20013, laugh - 2013)

Colin Perkins - not clear what changes people want to the RTP usage doc. tell me what i need to add. otherwise in reasonably good shape, since it allows extensions etc. 

Ted - Pls commit to running through the doc to see if there's any updates required by Sep 1

Keith - process question - who provides what updates?

Christer - should we wait for new version before we continue ongoing discussion

Ted - continue discussion

Cullen - Justin and I have some edits we need to do, don't need ppl to resend every comment ever, but please watch the new version

Christer - my issue is pranswer

Cullen - got that one

Colin  - not sure we should be relying on RTCweb editors to interpret the unified plan

Cullen - will vary for different issues. the ones where somebody needs to propose text, there will be coordination. 

A - i plan to go through the existing doc and decide what relevant text needs to be its own doc

M - process has lacked transparency up until now. doesn't want surprises, especially not in JSEP.  We need more consideration of the pranswer state machine.

Harald - timing for coordinating with w3c. Some chunks of work here are large. Maybe there should be some "future" references in docs we want to pass.

Christer - I already started looking into the bundle changes the unified plan will cause

Justin - lets not go pick through individual things now.

Cullen - let's not profile the standard now, but what's your timeframe?

Ted - when will JSEP be updated?

Justin - October 1

Ted - that's late

Justin  - i'll give you a date for a date: CoB tomorrow.

(Note Justin later provided around Sept 15 ) 

Bernard Aboba - we have a growing dependency graph, IETF doesn't do that well. Need a profile spec. The estimated completion date for all dependencies is horrifying.

M - don't think about it like this is a single thing - we need modularity, we're all going to take on modular pieces and release incrementally. concerned about profiling. 

Cullen - W3c doesn't even believe in versioning, what do we do here?

M - there are things we know are done, we should be able to say, "they're done, ship 'em"

(more discussion about how to push and finish docs)

E - know what things need to be done together, don't over-modularize. chairs, pls identify what we need for useful functionality and what needs to get bundled together to do that.

<> Security Doc updates

E - got feedback, made updates

M - uncertainty with draft-muthu ref in rtcweb-security

Keith Drage - make an explicit proposal to the list

M - concerned about mixed content being introduced in a renegotiation - E says we'll discuss later

E  - screen sharing requirements, trying to find a way to provide it as securely as possible

M - this is deeply coupled to U/X. also, what about app sharing, do entities being framed in need to consent? what if my content is being framed? he wants an explicit opt-in

E - not talking about DRM scenarios. cross-origin images, frames. should only apply to the browser doing the session itself. 

M - if there's another browser in the background, the site has no way of controlling what content is displayed on those browsers

E - is sharing the browser itself an important quality? is this a deal breaker if many things go black when you share?

Bernard - we support app sharing, screen sharing, etc, people share browser windows - MS today doesn't get down to any lower level

Jonathan Lennox - chrome sharing firefox, how would you figure out what the iframes do? we do scrape under, especially useful in the tablet environment. the JS shouldn't be able to get access to the list of available windows to share.

E - security model is funky

M - a dialog window saying "what do you want to share?" is the right U/X. you're in control if you enable screen sharing. 

E-  let's take this offline to a design team with more participation from browser sec folks

Ted - we have time, keep going

Justin Uberti - likes Martin's dialog window suggestion. 

Brian Rosen - should how what has been selected, agreeing

(missed name) - the use case here is tech support, must be able to show a tech exactly what's on your screen

M - maybe we need a way to constrain the request for screen sharing. you either need a way to designate what you're sharing or don't share anything.

E - the concern is co-browsing, say, where you don't have that kind of control

M - if i'm on site A and i want to share a tab onto the same browser, how's it work? self-sharing is  a different issue. see Moz Tow Truck

(Roberto?) (missed it)

Dan Druta - one use case is pay per view protected content - DRM

M - it is near-impossible without doing something with special privileges

Greg Maxwell - Knowing what's being shared and getting consent is important. But once you give consent, beware - site may do a weird pop-up that shared private info.

Ted - Okay, get together with EKR and dig into the details on this. Not a formal design team, just a discussion.

E - should we ban null ciphers? uncontroversial

E - keys and privacy - use a different key for each calling counterparty. difficult to track, but provides some persistence of keys so you can tell you're talking to the same party.

Richard Barnes - web crypto provides a good API for this.

E - expect new version shortly

Ted - reminder about going to rmcat. We're meeting again tomorrow.


Second set of raw notes

RTCWeb Minutes IETF87-Berlin Thu 2013-08-01

No agenda bashing.

August 1, 2013
9:00 to 11:30

-- Should SDES be part of  WebRTC security practice and, if so, how?
Presentations: (Discussion left to end of all 3 presentations)

-- Hadriel Kaplan - 10 minutes 

This is the gong show of presentations. Hold non-clarification questions to discussion section.

Do we mandate DTLS-SRTP be implemented and _used_ much of the time. Should we support SDES as MTI (or MUST NOT, or MAY). Anything other than MTI means some browsers won't do it.

WebRTC walled zone/SIP free zone metaphor slide

Several arguments in favor of SDES (see slides). Less clipping, easier for gateways, e2e SRTP for interwork cases, implementation experience, low complexity (assuming it does not degrade security)

Concerns: Eavesdropping, no PFS, downgrade attacks, unverifiable, not complicated enough :-)

Discussion of each concern: see slides. If you have an evil web server, you're doomed. 

-- Martin Thomson - 10 minutes 

(Speaker dons a "Comment 22" jacket. I hope someone got a picture)

Martin doesn't really like SDES, but it makes applications work better, and that's important.

Allows gateways without re-encryption. Less energy use :-)

DTLS-RTP gives better security properties. <irony>Big success in SIP</irony>. If any step of authentication is skipped or fails, you're back to SDES properties (but with extra RTT and auditing)

-- Eric Rescorla - 10 minutes 

Not much debate on facts, spin might be difference
SDES the keying system, not SDES from RTCP.

in SDES, the signaling server has the key. In DTLS-SRTP, the signaling server does not have key without an active/MiTM attack. With key continuity or identity, you can detect an attack by signaling server, identify other party, and audit.

Example that people really do audit.

Active vs Passive attack. Passive attack can act retrospectively. (Some people make a distinction between capturing data and looking at it :-) )

Passive attack can be invisible. Active attack cannot be hidden.

Can't "accidentally" mount an active attack. Passive can be accidental via logs, etc.

DTLS handshake trivial cost compared to media encoding. Clipping is not an issue. (DTLS with false start can be done with 1RTT. TLS-WG working on reducing dtls latency.) Working on single RTT for "repeat business". Option to delay alert until handshake complete.

Backwards compatibility--vast majority of media traffic is not encrypted. Of the SRTP use, most uses SDES.

Re-encryption: Probably need media gateways anyway (ICE, different codecs). Re-encryption not expensive. Many MCUs will re-encrypt anyway. Still have EKT if we need it.

Incompetence: DTLS is mandatory. SDES shouldn't be allowed because people will use it, even if they don't really need to. SDES is brittle--will people remember to sanitize logs? Let's not give people a foot-gun.

Malice: Trivial bid-down attack. Makes it easy to monitor. Can't distinguish intentional monitoring from other SDES scenarios. Isolated streams + DTLS-only protect from this.

People notice changes in javascript that effect lots of people.

Large Scale Monitoring easy with SDES, harder with DTLS-SRTP.

EKR Recommends Browser-based WebRTC implementations MUST NOT implement SDES.

Discussion:  45 minutes (What role does SDES play?)


Javascript has access to raw media. If you can't trust the javascript you are doomed. Recalling the same person may go through separate gateways--that won't raise a flag. 


Performance argument is a strawman. A number of problems with ekr's malice slide.

Dan ?: Proposals mislead on what a browser is. Is firefox OS a browser? Web-run time or not is the important question. W3C has clear discussions on defining web run-time.

Justin: Haven't discussed relative maturity of approaches. Bizarre bug reports on dtls-srtp. A lot more work for some people. Hard to argue that SDES for chromecast would be a big security problem. SDES may be better for some non-person to person communication.

Bernard: Doesn't buy clipping argument--will clip both ways. One possible performance issue could be large conferences, but need to evaluate EKT to decide.

Richard Asak (sp?): Not buying the passive attack scenario. Passive attacker still has to break TLS. (comments from audience that misconstrues the problem)

speaker: Need to see threat analysis between sdes and ekt. 

EKR: EKT properties substantially better than sdes. Must control an endpoint to use ekt. 

First speaker: the primary basis of crypto is computational complexity. Performance arguments need to consider this. Haven't seen performance analysis of EKT.

(Chairs as for Dan Wing to comment)

Steve Kent: Comparison ultimately about security. Agrees with ekr's security analysis. Passive attacks much easier with sdes. This is what people should worry about.

Joe Hildebrand: Webex does large conferences. Need access to plaintext for mixing, recording on behalf of users, pstn interop. Decrypt on server side anyway. A bit more computation doesn't matter. Rather have fewer choices, less opportunity for combinations and misconfiguration. DTLS is fine for them.

Greg Maxwell: Perfect fore knowledge would help. Would people implement sdes because it's easier? Would they upgrade to dtls due to security issues? Would misconceptions drive people to sdes? We can predict - virtually all RTP is unencrypted. The arguments for sdes would apply for unencrypted. SDES is a moral hazard. It will become ubiquitously used. We will never have ability to detect monitoring. Should not deploy except for when absolutely needed. EKT can handle many of those cases.

Hadriel: Agrees with Greg. Marketing issue at some level. Need to use strongest things we can or we will get bad wrap. Browser should mandate DTLS, but other entities may have different issues. Clipping problem is real [several on the floor disagree]. We need to make a decision today. Most of the arguments are fud.

Hannes: Surprised by two statements: 1) developers get things wrong. Solution is not make crypto go away, there are other solutions. 2) Powerful adversaries, might as well not fight them. Does not want SDES.

Martin: Foot-gun starts out loaded and aimed. Don't get the properties we talk about with incompetence. Question about whether the canary is effective. People will look for security problems. Distorting issue.

ekr: Question of developer incompetence. Security props of dtls apply iwthout idp or isolated streams. When he says incompetence, he's talking about things like logging. Clipping comments based on research. PFS should be mandated. Martins comments about problems in implementing--we see problems in all stacks. Justing should call ekr if you 
see problems :-)

Speaker: Real dev problems have been SDP, not DTLS

Speaker from genband: Most people still choosing non-encrypted. Users should have a choice in what to trust. No suggestion to let user decide. How many people are using secure tunnels [forest of hands]

Sam Hartman: When you use DTLS-RTP and don't allow SDES substantially increases the work of known passive attackers even if your developers are incompetent, users don't know anything, not using idp or key continuity. Gateways can be used. Substantially supports not allowing SDES, especially in browsers.

Justin: Browser chrome can show if SRTP can be used. Passive attack scenario is same for browsers vs web run-times. WebRTC is a byzantine cathedral of new technology. Will extend time before we have stable, working WebRTC. EKT not going to show up for a while.

Dan Wing: EKT is an avt-core wg item. Not updated in a while, but will be updating. Recent changes causes extra RTT, want to avoid. Need to reincorporate some older text. David G. working on a technique to do ekt stuff without the extra overhead. Cisco built ekt for telepresence services; didn't want to do crypto in switching devices. Video switching devices don't have problem with dtls-srtp with ekt. Dan is a co-author of SDES--and says please don't use it. Use DTLS-SRTP. Future is hopefully not gateways forever.

Allisa Cooper: Conversation not about the paranoids--much larger group. People accept mass monitoring if content is not included. CDR, etc has different rules. People are a bit more okay with content monitoring of non-voice things. Use of DTLS matches the norm for non-paranoids. Not a corner case.

Kalyani: Have both WebRTC clients and standard clients using same server. Need interworking between sdes and dtls. Can do i gateways, native support on each side, or ekt. SDOs like 3gpp need decisions they can act on. Need to consider mobile devices with managed, secure access. Long term don't want gateways. Universal security mechanisms in the future.

Jon Peterson: Commends Dan on disowning SDES. Passive attack arguments are persuasive. Don't do SDES.

Hadriel: DTLS-SRTP doesn't protect from monitoring. Usually gateway to cleartext. OTOH, webrtc has to be secure, can't depend on user choices.   Even in 3gpp model, browsers over public internet need to be as secure as possible. Web apps different story

Sean Turner: Need to pick one. Doesn't want best, wants better. Passive vs active problem better with dtls-rtp. SDES may lead to DISCUSSES in the future (we're watching you)

Chair: That seems to be general concern.

Speaker: metadata is extremely useful. Different treatment only due to regulatory differences. People choose convenience. People won't choose security unless they've been burned. 

Russ Housely: Was appalled at sdes as a sec AD. Let's not do it again.

Speaker: We're not starting fresh--must work with old devices. In his experience, there's lots of sdes devices. He wants to work with them with minimum effort. Does not want a MUST NOT.

ekr: Disagrees with comments about dtls always being gatewayed. Not true for web to web case. Wants to avoid any possiblity of getting sdes web-to-web

Wendy Seltzer: Echoes concerns about passive surveillance. Detection is important. Make default choices secure.

Hum Time:

chairs: Context applies to browsers, web run-times, or every possible application. Scope applies to browsers and things that use same technology as browsers. Discussion has been around sdes. Not at a point to make a decision about ekt. That option will remain open regardless of decision.

Question: Do we think the spec should say MUST implement SDES, MAY implement SDES, or MUST NOT implement SDES. (Current doc says MUST do dtls-srtp)

Substantially more support for MUST NOT than MAY or MUST

**** Consensus: MUST NOT implement SDES in the browser.

Hadriel: Does this preclude web run-time applications?
Chair: That term (web apps) does not make sense from a W3C perspective. Need to work through clarifying that.

-- Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents
-- Presentation: Adam Roach - 30 minutes

Adam presents slides on where various bits of work land.

RTCWEB needs an arch doc that points to all the other specs, updates to JSEP, RTP.

Discussion: 30 minutes

Keith: Need to confirm other groups will take the work.

Adam: Other items are in charter scope to other groups.

Martin: It's up to other groups if they want to scope things to rtcweb.
Fluffy: That doesn't move things to our charter.
Harald: In RTCWEB, I don't care what other uses other groups make of components. Architecture could go in overview doc if not too long.

Cullen (as chair): assumes most would land in overview and rtp usage draft. And jsep.

Actual docs are less important, as long as we do it.

Martin: Not sure jsep updates really covers all of this--what does it mean for jsep
Justin: A bunch of things have to go in sdp. jsep needs to specify what happens when you create offer, answer, etc. Waiting for unified plan to figure that out.

Christer: (quetion to justin) Is this partial offer and answer to be supported in jsep, or are they provided to browser some other way.
Justin: Through jsep.
Christer: This will be 3264+
Adam: Not real semantic change from 3264. True that jsep becomes 3264 + new stuff needed in mmusic.

Chair: If you own one of these docs, when can we expect new drafts?

Harald: Sept 1. Expects a version that points to docs at that time, may have placeholders.
Collin Perkins: Lots of arch doc stuff is already in rtp usage doc. Not clear what people want to see in rtp usage. Will add references as soon as we know which rfcs should be mandated. There are updates outstanding, but not should effect this. will try to have existing updates by Sept 1, but no promises.

Keith: Are we assuming existing editors will add stuff to their drafts. Who will work with MMUSIC etc.

Chairs: Will work with MMUSIC chairs. May press-gang people. Taking volunteers.

Christer: jsep question. Other issues being discussed. Should we hold discussion on those points until we have a new jsep versions?

Chair: would like conversations to continue.

Fluffy (as individual): Not sure we're at a point to need people to resend comments, but if things get missed in next version, please comment.

Collin: (follow up on Keith) : Not sure we should leave it to draft editors to interpret what needs to change. Need the working group to tell the editors.

Chairs: Need someone to put forth a proposal, then we can wordsmith.
Adam: Happy to work with editors to help figure out what mmusic has agreed to.

Chairs: Some things will need working group input, some things can be proposed by editors. Some things may not have a draft yet. Chairs will coordinate between working groups.

Collin: Proponents of unified plan need to offer concrete suggestions.
Adam: will put skeleton together of the parts that impact each draft.
Martin: There's been some transparency issues--want to avoid surprise changes in drafts. Please send email to list prior to changes.
(Chairs, Adam agree)

Martin: Consider implications of pranswer on partial offer/answer. Multiple parallel state machines. Big API change.

Harald: (as w3c chair) Question of time. Push towards something stable as soon as possible, so people have something to refer to.  Most of these items are not large. Bundle, Partial offer/answer stands out. May have "future" references to things we can't normatively reference yet. Need to finish in finite time.

Christer: Already looking into bundle changes, will communicate results.

Justin: Don't want to pick and choose on what things we need for 1.0 implementations, but may need to consider baseline. Need to consider what can be done now, what can be put off.

chairs: May need to profile standards, but not today. 
Chairs: When can we expect a jsep update?

Justin: Taking unified plan (not all partial offer details) in jsep Oct 1. (Chairs want it sooner) Justin: will answer by end of Friday.

Bernard: Need versioned profile documents. Profile that lives for all time is not a reasonable thing. Management issue. Dependency graph is horrifying.

Martin: Will implement things in their own time. Idea that this is any single things is delusional. Issue of modularity. Profile tends to happen after you make big monolithic thing, not realistic.

Chair: Profiling adds time to schedule. Document structure can do different things. Overall docs early, "how to " for specific use cases can come later.

Martin: Current structure doesn't support that.
Chair: W3C doesn't believe in versioning. How can we break this up?
Martin: (avoids comment 22)

Chairs: We may need some change in modularity, but don't wait on work. Technical decisions don't change due to doc structure.

Martin: Be good to be able to identify what is done and shippable. Close or passed that point with overview. Concerned that overview requires changes due to unified plan--it's too closely coupled.

Chairs: There was a debate on when to pub overview; decided to do it last. Please speak up if other drafts need to be split.

Martin: Or stabbed repeatedly.

ekr: This is a living standard. How do we deliver docs in a way that provide a story of what can be done? What subsets are required to do something useful? Need to be proactive identifying what's done and useful. Escalate decisions.

Chair: Need to track open issues better.

Security document updates
Presentation: Eric Rescorla - 5 minutes
Discussion: 10 minutes

Lots of feedback, last call comments, commenters. Will go over substantive changes people likely to have opinion on, a couple of open issues.

Added privacy considerations, discussion of IP location privacy and tor.
Edited SAS section re Alan's comments
Updated comm consent section
Added section about malicious peers
section on screen sharing threats.

Bernard: Can we avoid references to non work group items?
Martin: Need to make that go away somehow. Actual draft not a problem, but degree of uncertainty
Keith: Propose replacement on list.

-- security-arch

Forbid use with mixed content

Martin: Says cannot start with mixed comment, not must stop.

SCreen sharing permission reqs
requirement to surface NULL ciphers

Screen sharing has sec threats, but people want it. Added several normative requirement. (No permanent permissions, no bundling permission with other media permissions, must clearly indicate applications being shared.)

Martin: Deep coupling with UX style issues. E.g. different apps indicating sharing differently. Consent methods extensively researched to trade off with user annoyance concerns. Need to look at UX alternatives. Not sure how much goes in draft.

Martin: App sharing for browser, or entire screen sharing--there's another set of parties to consider in consent. Things being framed. May not want framing site to gain access. Should be explicit opt-in in spite of UX issues.

ekr: discussed previously. applies to browser doing introspection on self, not other browsers. Would like to here from someone doing video conference systems. This may make browser unshareable--is that a deal breaker?

Bernard: MS supports app sharing, screen sharing, and people do share browsers. Display iFrames that are in them. Doesn't get to that level of detail.

Jonathan Lennox: Checking other browsers is hard. System does scrape under. Necessary for single-window environments. JS shouldn't get access to list of available windows to share.

ekr: Site solicits what the user wants to share. Makes security model funky.

Martin: Task-focused Dialog of "what do you want to share" is valuable. Users can control sharing, maybe they can handle cross-site content.

ekr: Not going to finish this issue--need to take offline.

chair: Raise your concerns now, design team likely outcome.

Justin: Likes proposal for a select what you want to share dialog, not a yes or no. Users sometimes need to share two different browsers.

Brian Rosen: "share this window" UX difficult when you have to click on window on top.

speaker: Tech support use case requires sharing everything. 

Martin: For opt-in support, may need to constrain in ways that can identify "this" browser window. Expectation that you can request framed material explicitly opt-in, or don't frame it in the first place. "Black boxes" won't cause problem.

ekr: Issue is with co-browsing specific sites. Not an issue for generic co-browsing.

speaker: As a user, agrees with bullet 3 on clear indication of sharing.

speaker: user case: Pay-per-view protected content.
ekr: Those guys prevent any scraping.
Martin: True--can't get access to those bits.

greg maxwell: Threat model is you share, then have a private banking info iFrame pop up.

Chairs: Interested parties get together with ekr. Not formal design team for time purposes.

Null ciphers: Currently requires calling them out. Martin suggests banning them. Sounds like good idea to ekr.

Justin: Only reason to keep is they are useful for debugging.
Martin: Fine for debugging, but don't ship it.
ekr: Spec requirements can be overridden for debug config.

DTLS keys and privacy: Reuse good for security, but linkability. Current spec requires new key request mechanism. Not in W3C spec yet. Propose requirement for multiple persistent keys. Counter third party info leaks by encrypting more of dtls handshake. (already proposed for tls 1.3)

Richard Barnes: [missed comment] Will get together with ekr to discuss.

Next steps: More minor comments, missed a few comments, new version shortly after IETF.

Chairs invite people to attend RMCAT.