Minutes for PERC at IETF-93
minutes-93-perc-2

Privacy Enhanced RTP Conferencing
IETF 93
Session 2015-07-20 1300-1500: Congress Hall III

Scribe: Sean Turner , Alan Jonhston

Summary:
* Chairs kicked off the first PERC meeting

* WG discussed PERC requirements, WebRTC use cases and couple of solution
framework documents.

* Requirements document (draft-jones-perc-private-media-reqts-01)
  - is progressing in the right direction
  - might need more clarifications on scope of key management requirements.

* WebRTC use cases document (draft-westerlund-perc-webrtc-use-case-00)
  - more discussion is needed on key management functionality approaches,
    specifically media path key management vs out-of-band key management.

* Solution Framework documents (draft-jones-perc-private-media-framework-00 &
  draft-mattsson-perc-srtp-cloud-00)
   - There was an interest in using EKT to distribute SRTP master keys.
   - WG felt more discussion is needed on the scope of the Media Distribution
   Devices
     in terms of modifying aspects of RTP Header and RTCP messages.
   - EKT needs updating to reflect new extensions proposed in the framework
     documents

* Proposal was made to move EKT to PERC from AVTCore since it fits naturally
   with the PERC requirements. Decision pending a better idea of PERC
   requirements.

* Chairs to setup design team meetings to discuss the following items
  - Aspects of RTP/RTCP that can be modified by the MDD
  - Key management (generation, distribution, rekeying) approaches under various
    deployments (SIP, WebRTC ..)

------------------------------------------------------------
Raw notes (From Sean Turner)
------------------------------------------------------------

Chair Welcome Slides

Chairs started with looking at milestones and proposed drafts.
No agenda bashes required.

draft-jones-perc-private-media-reqts

Reviewed history of draft - it replaces
draft-jones-avtcore-private-media-reqts-01.

Roni: There are no requirements that address the KM map?
Paul: Do we need an explicit requirement and what would it be?

draft-westerlund-perc-webrtc-use-case-00

Mo: You're trying to protect that a site can enforce the end-to-end session. Is
that the JS enforcing something on the browser? Magnus: Not necessarily - the
browser needs to behave Mo: Is the users valifating something or is it the
user? Magnus: There are a couple of options here.  The import thing is that the
service can apply a policy and get it enforced. Mo: You want user control and
service control

Peter: When you say origin are they both referring to the server serving up the
media ... Magnus: It's the top page.

EKR: The underlying assumpton is that the web origin is associated with a
server not the KMF.  There's a KMF and somebody wrote the SFU? Magnus: You want
to stop a man-in-the-middle. EKR: the mental model is that the enterprise
contracts out and they provide a conference systems except the KMF so that the
conference system can be updated but ... Magnus: THere's one step before that
to run a server that loads the basic page and policy. EKR: You might do that
but that's not how Mozilla runs most of its services.

Peter: The origin server must be run by the party that wants end to end or is
it may. Magnus: So far it's a must. Peter: That's a great goal. ... EKR: I hope
it's just the KMF.

Adam: Just to be clear the implication is a standardized protocol for KMF?
Magnus: You need to have it secure for key retrieval.
Adam: I think that might be problemtic.  I want to collocate the UA with the
KMF(?)

Roni: Do you know that the client is going to an entity in this conference?
Magnus: Some yes - I would claim you need ot know the mode of operation.
Roni: There needs to be a requirement then.
EKR: it seems like you need to know there's a push and a double wrap nothing
else before that is useful.

Peter: I think this is a policy choice of the application (for clients to get
access before they join).  Some applications will want people to have early
access to content. Magnus: Agree it must be optional. EKR: I agree but I don't
see it as a reasonable required for real-time data. Peter: Building toward the
recording case.

Roni: You should the participant may join only for a short time.  When do you
want to do the rekeying. Magnus: Yes there's some implications on rekeying
here.  Want to make sure there's no impact on the quality of service provided.

Roni: I think some of the requirements are general problems.
Magnus: The problem is the trust model the middle boxes aren't trusted here.

EKR: (on the strawman solution) ONe thing that confused me is why are you
encrypting they key? Magnus: I don't think we're encrypting it. EKR: It's
encrypted with a key the client supplied? Richard: This is more about solution
that requirement so let's hold this convo.

Open Discussion

Roni: The first thing is does the end-point need to know it's about support
MTF.  There are some conferencing where you're getting invited from the
application so there a different flow so there's not really a login. Magnus: I
think I agree with Roni. Not all identities are people.  When it comes to
dialing out it doesnt' look that different.

Fluffy: I didn't see much about names that are displayed to users - it's
important that the people in the conference have an idea what conference
they're in.  We have to have something user visable. EKR: Right ... so ... I
guess ;) at present you mean something visible in the chome (yes).

Mo: Need to understand the user and site authentication trust models.
Richard: There's an tension between the desrie to not impact endpoints.

PHB: It solves a lot of problems if you just use a fingerprint thoughtout your
code.

Roni: I noticed something about only explicitly registered clients.  There can
be different models that allow open conferences. Magnus: Somebody that has
authority over the conference is the one to decide whether it's open or not. 
Those participants are the only ones who can join.

Adam: Curious about the point you're making about existing implementations -
there's ton of stuff changing so displaying stuff in the chrome doesn't look
that bad. Richard: Just saying that it seems like we want to minimize the
changes. Adam: Is the site forcing perc or not? EKR: Not sure I'm groking
force/expose Adam: It's perc or don't work. Richard: There'a more basic
definitional problem here- what do mean by do perc.  Not sure it's oberservable
from the endpoint. John: Knowing it's perc or not is not enough. EKR: The
machinery I expected is that the user is being asked to give permission for
media graned toward the KMF.
....
Fluff: The user experience we want to have moz using hangouts whitebox provider
and when you go to start the conference you authorize your camera to send media
conF#@moz and all the web interaction happened with moz@conference.com. Adam:
That's a forgone conclusion?
...
Paul: Need a use case document.
Colin: Need to make a decision on ruling TCP info (?) in or out of scope
Andrew: On active keep alives there are times in mobile networks where you
might be out for several minutes. Magus: Yes but there's a difference in the
set of people in the conf - you end up forcing a rekey. Ted: Any system which
is attempting to rejoin must be able to handle that the conference was rekeyed.
Active keep alives are horrible on the batteries of mobile devices.  How are we
going to be dealing with muting to rejoin later? EKR: Do we need to identify
multiple senders: bridge can assert the senders or it can be end-to-end.  The
last time we did sigs for RTP and now we can actually sign ever packet.

draft-jones-perc-private-media-framework-00

Adam: Clarification that changes are to ekt or a profile?
Paul: Changes not profile.
Adam: We should probably send requirements to the WG already managing it.
Paul: Not sure EKT is used in industry.
Adam: It belongs in the mmusic
Magnus: This group is specified to do this work so do it here.

Jon: ....
Paul: ...

Colin: there's an assumptoin that the MDD has access to the hop-by-hop.  We
might want to limit what information the endpoints put in RTP. Paul: It comes
back to whether we want to encrypt RTCP so far it's just been hop-by-hop. 
Endpoints just shouldb't put anything confidential into RTCP. EKR: As I
understand it here is that hte tradeoff is that thre's some info leakage. EKR:
Would be good to get somebody to write up what the middle boxes can do. Fluffy:
There's more in RTCP that I remember - need to do a privacy scan.  Either don't
use 'em or encrypt them. Justin: ...

draft-mattsson-perc-srtp-cloud-00

Peter: Are yo usaying the relevant RTP tops is exactly this list or just some.
John: These are the ones we know about.  I don't thinkwe should support ever
RTP topologies ever made. Magnus: There aren't really that many topologies.

Andrew: Are you just considering unicast?
John: multicast is out of sopce according to the charter.

Mo: You mean even if the speaker is switched out and doesn't come back for 10
minutes you want to force a continuous seq # John: I would say RTP enforces
that. Mo: I disagree with that requirement Colin: It's been there from the
beginning. Mo: Loss strategy needs to be rethought wrt perc. Magnus: Rewriting
seq # is possible and I think that's right accoridng to the RTP spec. 
Rewriting seq # should be open though. Colin: We need requirements that make it
consistent with 3550.  But what's being suggested isn't. Fluffy: The way this
slide is phrased is misleading (do not break RTP slide). Colin: I think there
are other ways to solve this without breaking the endpoints.

Jon: Is there a need for the ? to have semantics or can they be random?
John: In the IV formation case - yes.

Mo: I want to make sure existing policies can migrate.  Source data is send
unmolested through the middlebox.  Requiring middleboxes to do transfroms seems
unnecessarily.

EKR: I think we should understand there are two distict problems: Key
management and RTP screwaround.  We need to keep them seperate.  Can we do a
design team?  What to have ordinary endpoints to be the KMF. Colin: Agrees we
should try to seperate them out.

Steve: Want a use case document.

Mo: Good that they're both concentrating on GCM.  Also think about new work
like aero(?)

Magnus: Request that the framework - why is the hop by hop key from the KMF as
opposed to generating it by the two end points. Paul: The MDD is just passing
the connection to the KMF so it's kind of transparent.  Do this so the endpoint
when it does DTLS/SRTP/EKT it can do it point to point and the they're
behaviour is the same.  Do the key exchange in the media path and minimize
changes on the endpoint. Mo: To expand a bit - you could make other choices. 
How should the DTLS tunnel be deployed - in one implemention the MDD is like a
turn relay to the KMF.  You could also do two DTLS sessions. Fluffy: It's
desirable to be able to ensure the arrival is fast to make sure the key
delivery and media are in synch.  Deiverying identity info for point to point
is the same as conference call.

Richard: Design team for RTP bits that need ot be exposed to middleboxes? 
Seeing thumbs up. Bernard: Is this a decision about what points we're not going
to support of 3550? Richard: ... Colin: Again the SRTP spec has two parts - we
do need to consider both parts. Richard: jon, magnus, paul, justin, jon,
fluffy, colin, ekr, randell, maire

------------------------------------------------------------
Raw notes (From Alan Johnston)
------------------------------------------------------------

Tuesday, 1300 - 1500, Congress Hall III

Minute taker: Alan Johnston

Time            Length          Discussion Leader       Topic   Reference

1300 - 1310     10 minutes      Chairs  Administriva

Review of milestones
No agenda bashes

1310 - 1330     20 minutes      Paul Jones      Requirements   
draft-jones-perc-private-media-reqts-00

What changed
Some new requirements

Question about key management

1330 - 1350     20 minutes      Magnus Westerlund       WebRTC Usecases and
Framework   draft-westerlund-perc-webrtc-use-case-00

Use cases reviewed

Question about site forcing end-to-end security
Question about web origin being conferencing service
Question about who runs origin server
Question about standardized protocol for KMF
Question about does client need to know
Question about participant joiner is a policy setting
Question about rekeying timing
Question about moderator joining/rejoining

Straw man solution

Question about double encrypting key in Content-Encryption header field

1350 - 1405     15 minutes      WG      Discussions

Comment - should there be a requirement for endpoint support
Comment - how user knows what conference they are in - the name displayed to
user Comment - different views of trust model Comment - only use key
fingerprints to identify keys Comment - conferences can be joined in different
ways, sometimes you don’t know who will join Comment - degree of changes needed
for client to join a perc conference Comment - definition question - what does
“conference is perc” mean? Comment - what is user experience Comment - there is
a need for a use cases document Comment - there are few requirements on RTCP
Comment - active keepalives Comment - we could sign every RTP packet

1405 - 1425     20 minutes      Paul Jones      Solution Framework for Private
Media    draft-jones-perc-private-media-framework-00

Question about changes or profile of EKT?
Question about whether this WG is chartered to change EKT
Question about assumptions about what can be put in RTCP
Question about need for RTCP end-to-end

1425 - 1445     20 minutes      John Mattsson   SRTP For Cloud Services
draft-mattsson-perc-srtp-cloud-00

Question about relevant toplogies
Question about consecutive sequence number enforcement
Question about resilience and packet loss

1445 - 1500     15 minutes      WG      Discussions

Comment - Make sure present topologies can migrate to this one, avoid inflation
of packet headers Comment - Separate documents for key management and SRTP
modifications Comment - a use case document would be useful Comment - Aligning
on GCM is good, watch our new Aero ciphers Comment -

Chairs - What about a design team for SRTP about end-to-end vs hop-by-hop bits

Comment - include RTCP.

Volunteers identified as: John Mattson, Paul Jones, Jonathan Lennox, Colin
Perkins, Randall Jessup, Eric Rescorla.
======================================================================================