Minutes RTCWEB session 1, Aug 1 2013 Berlin IETF 87 Chairs: Cullen Jennings, Ted Hardie, Magnus Westerlund (on leave) Scribes: Jon Peterson and Ben Campbell Conclusions day 1: 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. RTCWEB session 2, August 2, 2013 Chairs: Ted Hardie, Cullen Jennings (Magnus Westerlund on leave) Minute takers: Suhas Nandakumar, Bernard Aboba Session recording: http://www.meetecho.com/ietf87/recordings Agenda: Note well Review of document status: http://www.ietf.org/proceedings/87/slides/slides-87-rtcweb-6.pdf Open Issues in draft-ietf-rtcweb-use-cases-and-requirements: http://www.ietf.org/proceedings/87/slides/slides-87-rtcweb-12.pdf Open Issues in draft-ietf-rtcweb-data-channel and draft-ietf-rtcweb-data-protocol: http://www.ietf.org/proceedings/87/slides/slides-87-rtcweb-10.pdf Decisions taken, subject to confirmation on the list: For draft-ietf-rtcweb-use-cases-and-requirements: Document is ready to go to WG last call. For draft-ietf-rtcweb-data-channel and draft-ietf-rtcweb-data-protocol: We will adjust the IP layer initial PMTU from 1280 to 1200 and document in the draft the reduction from 1200 to get to worst case scenario headers, then put the number in terms of the SCTP layer. We will replace strict priority with weighted fair queuing between priorities. Randall Stewart and Michael wil write a proposal that reliable unorderded channels be ordered until there is receipt of a message that indicates that the OPEN has been received. Details will be in the proposal. Will update the documents to require that sender-side congestion control be used, but not require support for delay-based congestion control. More discussion is needed on how to handle fragmentation and reassembly when PPID based option is not available; the group discussed message size limitation, but did not conclude whether or not this was acceptable. Raw notes below Day 1: Ted: intro Ted: noting that we need to follow the recent consensus of MMUSIC on bundle <> SDES Hadriel 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. Martin 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. EKR (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 Kalyani- 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 Peon - 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 for day 1 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. Big success in SIP. 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?) Hadriel: 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. Martin: 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. August 2, 2013 Chairs: Ted Hardie, Cullen Jennings (Magnus Westerlund on leave) Minute takers: Suhas Nandakumar, Bernard Aboba Session recording: http://www.meetecho.com/ietf87/recordings Agenda: Note well Review of document status: http://www.ietf.org/proceedings/87/slides/slides-87-rtcweb-6.pdf Open Issues in draft-ietf-rtcweb-use-cases-and-requirements: http://www.ietf.org/proceedings/87/slides/slides-87-rtcweb-12.pdf Open Issues in draft-ietf-rtcweb-data-channel and draft-ietf-rtcweb-data-protocol: http://www.ietf.org/proceedings/87/slides/slides-87-rtcweb-10.pdf Decisions taken, subject to confirmation on the list: For draft-ietf-rtcweb-use-cases-and-requirements: Document is ready to go to WG last call. For draft-ietf-rtcweb-data-channel and draft-ietf-rtcweb-data-protocol: We will adjust the IP layer initial PMTU from 1280 to 1200 and document in the draft the reduction from 1200 to get to worst case scenario headers, then put the number in terms of the SCTP layer. We will replace strict priority with weighted fair queuing between priorities. Randall Stewart and Michael wil write a proposal that reliable unorderded channels be ordered until there is receipt of a message that indicates that the OPEN has been received. Details will be in the proposal. Will update the documents to require that sender-side congestion control be used, but not require support for delay-based congestion control. More discussion is needed on how to handle fragmentation and reassembly when PPID based option is not available; the group discussed message size limitation, but did not conclude whether or not this was acceptable. Detailed notes: Goal: figure out what the blockers are to going to WG (and eventually IETF) last call. Current Draft Status (Cullen Jennings) What are the dependencies to bring this work to conclusion? About the percent done numbers: * They are wrong * None are overly precise * Don't include normative dependencies Spreadsheet with documents, dependencies, start and percent done are shown. Looking at start date and percentage document, you conclude that either we are far away from being done, that we need to accelerate them, or that we need to cut dependencies. Andy Hutton: Need to complete use cases and requirements, then we can review where we are against the requirements. My understanding is that the entire WG can't be done until we have met the requirements. If there are requirements that are not to be addressed at this point then this should be a decision made by the working group. I believe http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations should be on the list of RTCWeb related drafts. This is because it is currently the only draft that addresses the firewall related requirements in the use case and requirements drafts. Don't disagree with the 70 percent estimate. Cullen: The WG doesn't need to meet its requirements, it needs to decide which ones it will meet and when. Muthu: Behave has declined to make draft-muthu-behave-consent-freshness a WG work item. Cullen: Proposal is to take the text out and put it into an existing WG work item, such as draft-ietf-rtcweb-security and/or the media doc. Martin: Concerned that adding draft-muthu to the security document could delay it. Harald: processes are there to get work done. Let's get it done fast. Gonzalo: I am all for pragmatism. I got pushback from IESG for too many AD-sponsored docs, so needs to be run by them. STUN and TURN URI docs are AD sponsored. Gonzalo is not handling draft-burnett-rtcweb-constraints-registry. What is the status of this? Dan Burnett: Needs AD sponsorship, but doesn't have it. Ted Hardie: W3C could request an IANA registry. Dan Burnett: That process has been inefficient in the past. Gonzalo: I will talk to them and figure out a way to proceed. Martin Thomson: we accepted draft-nandakumar-mmusic-sdp-mux-attributes as a WG work item. Emil Ivov: draft-ivov-mmusic-tricle-ice is accepted as a WG work item. I think we are close to WG last call. Cullen Jennings: Can you submit what you have ASAP? Emil: Yes. Cullen: draft-dhesikan-tsvwg-rtcweb-qos has not been accepted as a WG work item. Cullen: If the draft says you MAY implement VP8, this becomes a normative dependency. But draft-ietf-payload-vp8 is in IETF Last Call. Cullen: The circuit breakers document has not gotten a lot of review. Colin Perkins: We need implementations of circuit breakers to check when it would fire and when it won't. Jonathan Lennox: Adam put up a list of items implied by the adoption of unified. Will you do an updated (more depressing) version? Cullen Jennings: We have no WG document on simulcast (only document added of super-relevance). Jonathan Lennox: Also App-ID. Cullen: agreed. Martin Thomson: Also partial offer-answer. Cullen: Yes, that is also depressing, you are right. Jonathan Lennox: draft-ietf-avtcore-multi-stream is now three documents. No new text, just divided up. Colin Perkins: The audio document is a dependency of RTP usage. Bernard Aboba: Does it make sense to move the text of that to RTP usage? Colin Perkins: No. Ted Hardie: Yesterday we went through the security drafts. We will bring those to WG last call unless we decide to add consent freshness to it. Please review them. Martin Thomson: There is a concern about screen sharing. If they are to include that, it will be premature. That part is only 30 percent done. Ted Hardie: Maybe we should reference ongoing work on that (separate document on screen sharing). Martin Thomson: That might be reasonable. Martin Thomson: There is also the URI scheme. EKR: Yes. Use-Cases and Requirements (Christer Holmberg presenting). Christer: This will be short. I am Christer. Christer: Next slide, next slide, next slide. (3) Next Step: WGLC call Cullen: Hum in favor of WG last call (laughing). Christer: My suggestion is to start WG last call again. EKR: The date is wrong! It says 2014? Are we in the future? Cullen: Does anyone thinking that we shouldn't send this to WG last call? No one speaks up. DECISION: Use-Cases and Requirement docs to go to WG last call. Data Channels Ted Hardie: If you can get consensus in the same amount of time, I will buy you the most expensive bottle of champagne in Berlin. Presenter: Next slide (laughs). Changes to draft-ietf-rtcweb-data-channel-05 Integrated RTCWEB-specific considerations from draft-ietf-tsvwg-sctp-dtls-encaps Update references. Changes to draft-ietf-rtcweb-data-protocol-00 Improved grammar, fixed typos Added clarifications Stream usage based on DTLS client/server role Cleanup of DATA_CHANNEL_OPEN message format Allow external negotiation of data channels Improved IANA section Open Issue No 1: PMTU Issue; Initial PMTU for IPv4. Proposed Resolution: Use 1280 (like IPv6) EKR: When you say use 1280, you mean 1280 minus UDP, DTLS and SCTP header? DTLS header and wrapping will depend on cipher suite. Randall Stewart: If 532 is the minimum for a fragment, is 1280 too big? Hadriel Kaplan: Is there a path PMTU check, or just use local MTU? Just talking about the initial one? Hadriel: Does browser do Path MTU discovery? You're not expecting that, right? Ted Hardie: It is the initial MTU before you start PMTU discovery. It is NOT the local MTU. Justin Uberti: There is also potential TURN overhead. So it might be 1200 bytes with that taken into account. 1280 is the MTU at the IP layer (no link layer overhead). Say "1200 plus headers" instead. EKR: We assume that the underlying network has 1200 MTU, So use 1200 MTU For the MSS minus the headers. Let us focus on the SCTP layer. Martin Thomson: You know how big IP and UDP header is, can assume what DTLS is doing. EKR: Assume that the IP packet is 1280 bytes. Comments from Jabber: 1280 minus worst case headers (not actual). Why does a browser need to do packetization? Justin Uberti: 1280 bytes in a reasonable guess of what the browser can put on the wire (at the IP layer). Cullen Jennings: Two issues. Before headers get added and after. It would be easier if the number specified in the doc was related to SCTP layer, not IP layer. Next question is what is the size? At IP layer, we have problems with voip clients with 1280 before, where there was VPN activity. So we used 1200 and had better success with this, as a number at the IP layer. Jonathan Lennox: When dealing with worst case you need to assume TURN is present even if you are not using it, because someone else might be. DECISION: We will adjust the IP layer initial PMTU from 1280 to 1200 and document in the draft the reduction from 1200 to get to worst case scenario headers, then put the number in terms of the SCTP layer. Open Issue Issue No. 2: Data Channel Priority Priority of data channel unspecified. Proposed resolution: Use them as strict priorities between the data channels of a peer connection. Covered by an SCTP stream scheduler. Richard Ezak: Strict priority seems draconian. You are blocking lower priority flows. I do not have a firm opinion. Michael: This is what we have in the implementation (not specific to RTCWEB). Stream scheduler can provide almost anything, but needs to be specified and implemented. Martin Thomson: I would encourage you not to do strict priority. Don't have higher priority starve out lower priority streams. Bernard Aboba: Could be bad if you had a signaling data channel and it was starved out by another data channel (e.g. file transfer). Jabber room: No need for priority. Why are two data channels open anyway? Martin Thomson: I disagree. We have a wide variety of applications using this. Ted Hardie: Having priorities but not saying what it means is under-specified. Applications should know when they are emitting streams with priorities even if there is an implementation-specific rather than designated strict priority, that strict priority might happen. So they need to pay attention or starvation could occur. Application-specific is really the same as strict priority. I don't want this to be a research project not done in the timeframe of this WG (speaking as an individual). I would say that this is implementation specific (and treat this as if we have implemented strict priority), say updates may require updated stream scheduler behavior to pick a fair queing algorithm. Fluffy: makes a face (not as esteemed friend). Ted Hardie: Application can't behave differently as implementation specific vs. strict priority. Dan Druta: We have a proposal for a media stream priority, and relative priority between media stream and data channel is important. The priority specification by data channel is desired by developers. Michael: This is out of scope - only about what happens between data channels. Dan Druta: Understood. Martin Thomson: I agree with the sentiment, but not the conclusion. If you do strict priority, you end up with starvation. Ted Hardie: Can you suggest a default queuing algorithm that would be good enough? Martin Thomson: Weighted fair queuing. Ted Hardie: Who understands what weighted fair queuing is? Half a Dozen people raise their hands. Michael: Current scheduler has priority - within same priorities it schedules round-robin. Between different ones it is strict. Richard Ezak: Weighted fair queuing is adequate - would recommend against strict priority. Cullen Jennings: Six gallons of **** in a five gallon pail needs a lot of surface tension. Jonathan Lennox: Even if HTTP 2.0 case is more complicated than needed, browsers will be implementing an HTTP 2.0 scheduler, maybe recommend that we use the same scheduler, since it will be in the browser anyway. Congestion control coupling is a distinct issue. Ted Hardie: If you have a concern, hum now. Hums. If you believe current situation is sufficiently specified, hum now. (No one hums). Ted Hardie: Proposal to replace strict with Weighted Fair queuing between priorities. In favor? Hums. Opposed? No hums. DECISION: Replace strict with weighted fair queuing between priorities. Open Issue NO 3: Handling of early data. How to handle data arriving before DATA_CHANNEL_OPEN. Buffer it for how long? Proposed resolution: Buffer on order to 10 seconds. But a lot of messages can be transferred in that time. Suggested limit: At least 100 KB. Bernard Aboba: There are tradeoffs. If you set the time at 10 seconds, you are limiting the number of retransmissions, so reliability is limited. The 100 KB limit will depend on the usage scenario. For a game which sends occasional messages, it might take a long time to exhaust 100 KB. But if you are sending a file at high BW it might take long. Greg Maxwell: Setting a time limit, you limit the bandwidth. EKR: I am a sad panda, thinking about having "reliable transmission" not be reliable. Cullen Jennings: I proposed a response to the DATA_CHANNEL_OPEN. That way you know if it is received. Also, minimum buffer size is zero. Counter-proposal: The application MAY buffer (guarantee is zero), whenever it runs out, if it has not received the DATA_CHANNEL_OPEN it resets the data channel. Harald Alvestrand: Like two way handshake in case of failure. Applications have to handle channel reset, doesn't add complexity. Martin Thomson: There is a high probability that any loss will cause a stream reset if the buffer is zero. In effect you are letting the application set its own retransmission timer. Jabber room: Regarding Cullen's proposal, endpoint should not be required to wait for response (though it could if it wanted to). Can't distinguish why the channel was closed. EKR: I open up a data channel and set it for reliable, start transmitting, and if any packet is lost, then I have a high probability of having the data channel be reset if there is zero buffering. Ted Hardie: Reset only occurs when receiver gets more than it is willing to buffer prior to receipt of the DATA_CHANNEL_OPEN. EKR: Why are we doing this. Just to save one RTT? It is horrific! Ted Hardie: You must always be able to deal with a channel reset due to lack of resources. Cullen: If you have 5 percent loss how often does it fail with zero buffer? Answer: 5 percent of the time. Jabber room: This is unreliable if the buffer size is zero. Bernard Aboba: If you increased the buffer size and did the reset it might be reliable enough. Hadriel Kaplan: The basic problem is that you are not delivering what is claimed - the DATA_CHANNEL_OPEN is not actually being delivered reliably. Michael: Another proposal: Send the data reliably until the DATA_CHANNEL_OPEN is received. EKR: If you put zero buffering in the draft, then people will do that. My understanding of one-way handshake was to minimize round-trips, but I would prefer Cullen's proposal for a response. Ted Hardie: Please review the latency characteristics of that, and make sure you can live with them. EKR: I could also live with making the data reliable until the DATA_CHANNEL_OPEN is received. That approach does not require a two-way handshake. Ted Hardie: Randall Stewart and Michael should write a proposal that reliable unordered channels be ordered until there is receipt of a message that indicates that the OPEN has been received. Details will be in the proposal. Agree? Hums. Disagree: No hums. DECISION: Randall Stewart and Michael to write a proposal that reliable unorderded channels be ordered until there is receipt of a message that indicates that the OPEN has been received. Details will be in the proposal. Open Issue No. 4 Issue: Delay based CC required. Support of negotiation or sender side only behavior required. Possible coordination of CC between data channels and media streams. Proposed resolution: Don't require the support of a delay based congestion control Reconsider CC of data channels after RMCAT has provided a CC for media streams. Welzl: I agree with this plan. We need to think through if it makes sense to add negotiation of congestion control to SCTP. Cullen Jennings: What should we do instead of negotiating congestion controls? Welzl: Sender-side congestion control (negotiation not needed). Bernard Aboba: Does this mean that SCTP will use loss-based congestion control and starve out delay-based media congestion control? Cullen nods head. Bernard Aboba: This sounds bad. Is there a workaround? Potential workaround: Congestion Window of SCTP data channel can be limited by a socket option. Ted Hardie: We propose that sender-side congestion control be used, but not require support for delay-based congestion control. Objection? No objections. DECISION! Open Issue No. 5: Fragmentation and Reassembly PPID based fragmentation method only works for ordered reliable data channels Proposed Resolution All implementations must support the PPID based method for ordered reliable data channels. For other data channels the message is limited to avoid head of line blocking. When SCTP level interleaving (draft-stewart-tsvwg-sctp-ndata) is available, it is used and the length restriction for unordered or unreliable data channels is removed. Cullen Jennings: I propose we not resolve this issue right now, leave till later. Ted Hardie: This is not a unique problem for RTCWEB users of SCTP, it is generic. Generic solution should come with SCTP mechanism. Would be advisory only. Martin: If we want compatability with Websockets we need an 8 exabyte limit. If you are OK with message size limits for the channels which don't support PPID fragmentation, hum now. Low hums. If you are not willing to live with that, hum now. No hums. If you don't have enough information. Hums. DECISION: Sounds like more discussion needs to take place on the list.