Minutes for RTCWEB at IETF-87
minutes-87-rtcweb-3

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. <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?)

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.