Minutes for PERC at IETF-96
minutes-96-perc-1

Privacy Enhanced RTP Conferencing
IETF 96
Session 2016-07-22 1000-1200: Tiergarten

Scribe: Bernard Aboba, Joe Hill, Olle E Johansson

Summary:

* Chairs to restart virtual interims to discuss open issues/work items.

* Solution Framework documents (draft-jones-perc-private-media-framework)
  - framework needs to consider mapping with the RFC7667 RTP topology Spec
  - authors to update entity trust section on Identity establishment
  - close open issues related to end-point/conference mapping and others.

* SSRC Immutability Discussion
  - WG discussed SSRC mutability vs immutability options
  - no consensus reached in the room
  - Emil asked to submit draft explaining the impact of ssrc mutability on
    security/ssrc collision/end-point procedures in the perc context.

* SRTP Double (draft-jennings-perc-double)
  - needs to address how e2e headers are dealt with

* Tunnel Specification (draft-jones-perc-dtls-tunnel)
  - authors discussed various tunnel transport options (udp/sctp/tls)
  - concerns related to "firewall traversal" and "DTLS 1.3 message changes" were
    discussed with the current DTLS based tunnel proposal.
  - alternative options for tunnel design related to HTTP/Datachannel(SCTP)
     as the control plane protocol were discussed.
  - authors to submit updated draft to consider TLS for tunneling DTLS message.
  - authors to consider Tunnel protocol's extensibility mechanisms as part of
  the updates

* EKT Specification (draft-jennings-perc-srtp-ekt-diet)
  - TTL to be a relative time rather than absolute time.
  - extensibility for adding new ekt messages. Authors to discuss this on the
    mailing list.

------------------------------------------------------------
Raw notes
------------------------------------------------------------

*** Agenda bashing
- SOme confusion on who's presenting what, quickly sorted out

-- Virtual interim
- RB will start discussion on list

--- Presentation: Draft-ietf-perc-private-media-framework-01 (David Benham)

* Action items
  - Media distributor requirements and constraints to rfc7667 topology mapping
  - List of RTP header extensions that should/must not be encrypted
  - There may be others
  - Mapping of endpoints-to-a-given-conference may need to be conveyed
  - Possibly add ability for transmit-only devices not trusted for two-way media
  - Expand entity trust section (certificate fingerprint via signaling,
  identity assertions)

Roni: YOu want to identify to the key management
Adam Roach: Need to map to WebRTC and SIP
Richard barned: We should look at the feasability
Cullen Jennings: EKT doesn't support this (as EKR said) and I don't see a
strong need for this

--- Presentation: SSRC immutability - Emil Ivov
  - Emil: Risky to hinge PERC support on RID (not clearly specified, not
  implemented) - Emil: Do not prohibit SSRC changes in Perc - Peter Thatcher:
  The real issue is whether the endpoint can receive simulcast or not - Adam:
  To claim that simulcast is going to hold it up is wrong. Simulcast is in WGLC
  and we're not close - Colin Perkins: The discussion to have is where we want
  the complexity?  A simpler middle box or more complexity in receivers?  It is
  a design philosophy. - Discussion about SSRC collissions and how to handle
  that - Jonathan: this is what RTP topologies is supposed to handle/solve -
  Roni: Do we trust the middlebox or not? Richard: On one side: If we continue
  to require SSRC being inmutable, we have a dependency on RIB
      On other side: SSRC Collissions, two ssrc's being handled

      Quick hum: Two options:
           - Keeping requirement that SSRCs being immutable
           - Allowing mutability
           No consensus declared - back to mailing list

    Cullen: We need Emil to write a draft to be discussed, describe what
    happens on the endpoints

--- Presentation: Double - Drat-ietf-perc-double-01 - Cullen Jennings

  - Which RTP headers are added by the Media distributor
  - Jonathan : Adding end2end headers later will be really hard
  - Harald: Need to note that PERC doesn't give any security protection for
  end2end headers

--- Presentation: DTLS Tunnel Protocol - draft-jones-perc-dtls-tunnel - Paul
Jones

Concerns with current draft
 - Using DTLS between key distributor and media distributor presents NAT/FW
 traversal challenges - Current protocol is very limited in terms of
 extensibility - Current protocol is tightly coupled to specific DTLS messages
 that will change in DTLS 1.3

EKR: Why are we not using https rest as a control plane?
EKR: Proposal: Simle encapsulation protocol used as an outound connection from
key distributor to media distributor (slide 5 without message type 2 and 3)
     Using JSON data structures

Adam: No one seems to be in favour of data channels, we're down to a single TLS
connection. Need mailing list discussion. Cullen: ...or two connections...

--- Presentation: draft-ietf-perc-srtp-ekt-diet - Cullen Jennings

Jonathan: Keep message types outside of encryption to assist Wireshark

-- End of august timeout for reviews

-- End of session --

Jabber log:

10:05 Bernard Aboba [aboba@bluebox.internaut.com/jitsi-1fm10c0] entered the
room. 10:05 Nils Ohlmeier
[_716589068@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room.
Olle E. Johansson at IETF Berlin (GMT+1 DST) 10:05 Slide: Milestones &
Documents 10:05 Richard Barnes (chair) speaking 10:06 Slide: Agenda Bernard
Aboba 10:06 Richard:  Have adopted documents.  Drafts welcome on integration
with SIP and WebRTC. Olle E. Johansson at IETF Berlin (GMT+1 DST) 10:06 Adam
Roach speaking Bernard Aboba 10:06 Richard:  Agenda Bash. 10:06 Cullen: 
Assumed I was presenting, so I have slides. 10:07 Richard:  Will add a brief 10
minute slot on SSRC immutability. 10:07 Maire Reavy
[1318252808@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room.
10:07 m&m [linuxwolf@outer-planes.net/tradegate] entered the room. 10:08
Vincent Roca [_136287043@tiergarten.conf.meetecho.com/MeetechoWebLite] entered
the room. 10:08 bergtau
[bergtau@jabber.de/c88261a9-e64c-44f0-a76e-89f5a94e0927] entered the room.
Bernard Aboba 10:08 Richard: Should we pick the tempo back up with respect to
virtual interims? 10:09 David Benham: Framework discussion. 10:09
(draft-ietf-perc-private-media-framework) 10:10 David: In Buenos Aires we
adopted 3 working group drafts, including framework draft.  Everyone has ready
it, right? 10:10 David:  Differences in -01. 10:10 David:  Reduced acronyms.
Olle E. Johansson at IETF Berlin (GMT+1 DST) 10:11 Notes on Etherpad - please
help out and keep and eye on it.
http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-perc?useMonospaceFont=true
10:12 Jonathan Lennox [jonathanlennox@jabber.org/Vidyo-LT0519-M] entered the
room. Nils Ohlmeier 10:12 Did other people also lost video and slides from the
room? Bernard Aboba 10:13 David: Outer SRTP master keys created by each
endpoint. A conference-wide encryption key used to encrypt endpoint 10:13
"Outer" master key. Jonathan Lennox 10:14 Nils: as I understand it Meetecho
should have a button to restart your streams. Nils Ohlmeier 10:14 Jonathan:
yeah clicking like 10 times on the refresh got me at least the slides back
Meetecho 10:14 yes, audio can be restarted with a button in the upper left
(speaker icon circled by two arrows) Sean Turner 10:15 nope - working fine here
Meetecho 10:15 video streams by hovering on the stream and clicking the half
crcled icon 10:15 no need to click i tten times, though, just give it some time
10:15 (unless it takes way too much time, that is...) Bernard Aboba 10:16
David: Constraints to rfc7667 topology mapping:  TOPO-PtP-translator or SFM
w/single common SSRC space 10:18 David: Add a list of RTP header extensions
that should/must not be E2E encrypted? 10:20 George
[gpolitis@jabber.at/116737183237570818411469175552932937] entered the room.
Bernard Aboba 10:20 David; Possibly add ability to transmit-only (one way)
10:21 Deb Cooley left the room. 10:22 Deb Cooley
[1060721590@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room.
Bernard Aboba 10:22 EKR:  What is the use case? 10:22 Cullen:  An announcement
server that says "Cullen Jennings joined the conference". 10:22 Jonathan:  How
strong is this requirement?  Are you willing to drop it? 10:23 David:  Someone
brought it up on the list. 10:24 Roni:  This bullet raises an issue which is
not discussed.  You say MDD is not trusted content.  But this says it's not
trusted with the media distribution. 10:25 EKR:  I am assuming this is an E2E
requirement.  So you need different directional traffic keys.  You extract
different keys in each direction anyway, but this requires extracting 4 keys: 
RTP and RTCP in each direction. 10:25 EKR:  Could require surgery in EKT. 10:26
Cullen:  EKT doesn't support this but we could do it.  Use case when someone
joins a conference, can be delivered out of band, so we don't need to deliver
through the audio channel.  I do not see a strong need for this, personally.
10:27 Paul:  Explains how it could be added to EKT. 10:27 Randell Jesup left
the room. Bernard Aboba 10:28 Adam:  We already have hop-by-hop keys. 10:28 Mo
Zanaty:  One of the suggestions was to allow mixing of PERC and non-PERC media.
10:29 Mo Zanaty:  Difficult for endpoint receiver to know whether it is trusted
or not. 10:29 David:  Started a section on identity trust. 10:30 Emil on SSRCs
and immutability. 10:30 George left the room. Bernard Aboba 10:30 Emil:
Currently, PERC says that an MDD cannot rewrite SSRCs.  There has been a lot of
discussion around this. Sean Turner 10:31 emil protesting the pink box Bernard
Aboba 10:31 Emil: For me, this is quite problematc.  SSRC overwrites are used
for active speaker switching (one SSRC as main speaker). 10:31 Emil:  There is
also simulcast.  Sender sends multiple layers, but receiver gets a single
stream. 10:32 Emil:  I am specifically concerned about simulcast case.  Only
way to make it work with WebRTC (SSRC overwriting). 10:33 Emil:  There is also
RID-based approach.  Not clearly specified yet. 10:33 Emil:  No motivation in
SFU to add support for RID.  Why do it if you already have simulcast? 10:34
Emil: Supporting PERC in SFU requires two branches of code - one to support
WebRTC, and a separate branch for PERC (incompatible with WebRTC). 10:34 Emil: 
These arguments are against making RID the only way to use PERC. 10:35 Emil: 
Change is not to prohibit use of RID or to prohibit simulcast reception. 10:36
Peter Thatcher:  RIDS are just there so you don't have to signal SSRCs.  So
it's a red herring. Real question is whether endpoint can receive simulcast or
not. 10:36 Peter Thatcher:  Receiving simulcast a small part of total work....
10:36 Emil Ivov:  There is so much work, so why not add more?? 10:37 Peter
Thatcher: In a future version of WebRTC that supports PERC can we also support
simulcast? 10:37 Simon Pietro Romano
[1204262422@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room.
Bernard Aboba 10:37 Peter:  ORTC already supports reception of simulcast (with
two implementations) 10:38 Adam:  RID work is more mature than PERC. 10:38
Vincent Roca left the room. Bernard Aboba 10:39 Richard:  Would anyone like to
address benefits of immutable SSRCs? 10:39 Colin Perkins: An architectural
comment. Architecturally, we could implement this in either way. 10:40 Colin
Perkins: The discussion to have is where we want the complexity?  A simpler
middle box or more complexity in receivers?  It is a design philosophy. 10:41
Lorenzo Miniero [1182989666@tiergarten.conf.meetecho.com/MeetechoWebLite]
entered the room. Bernard Aboba 10:41 Colin:  Technical point.  Does collision
logic work? 10:41 Nils Ohlmeier left the room. Bernard Aboba 10:42 Mo:  It can.
This is how it would have to work to have a common SSRC space. 10:42 Colin: 
Not as simple as carrying the original SSRC. 10:42 Nils Ohlmeier
[2004610944@tiergarten.conf.meetecho.com/MeetechoWebLite] entered the room.
Bernard Aboba 10:44 Mo:  What I thought was your original main point. For each
participant there is a single decoder pipeline. 10:44 Mo:  If it is simulcast
reception you have a new decoder pipeline for each resolution. 10:45 Mo:  This
is why some architectures choose to receive different qualities (but not
multiple streams). 10:46 Emil: At WebRTC client level there is no support for
receiving multiple streams, so that is why the SFU rewrites. 10:46 Mo:  Since
WebRTC browsers do not support this, you are worried about this?? 10:46 Emil: 
Maintaining two ways of supporting simulcast also is not thrilling to me. 10:47
George [gpolitis@jabber.at/2900618927793902391469177245586653] entered the
room. Bernard Aboba 10:47 Cullen:  How does this work for audio? 10:47 You have
disconnected 10:48 You have connected Bernard Aboba 10:48 Emil:  It is not
needed for audio. 10:48 Olle E. Johansson at IETF Berlin (GMT+1 DST) has set
the topic to: PERC @ IETF96 | Agenda:
https://www.ietf.org/proceedings/96/agenda/agenda-96-perc Lorenzo Miniero 10:48
Emil is not saying there's no support for receiving multiple streams: just that
it is not fast and effective enough to make it transparent and immediate in the
client experience 10:48 SSRC overwriting does Bernard Aboba 10:49 Cullen:  If
the middle box can switch SSRCs, can take packets from one... 10:49 Emil:  Can
send the original SSRC in the packet... 10:50 Ben Campbell
[ben@nostrum.com/avalon-air] entered the room. Bernard Aboba 10:50 Jonathan: 
Emil is saying that he is going to need to maintain this mechanism until
everyone endpoint that only supports the original way is decommissioned.  And
he does not want to maintain two code bases for this. 10:51 Emil:  Don't agree
that there is a security vulnerability. 10:52 Jonathan:  Emil wants a different
RTP topology than translator or single SSRC space.  So this gets into the
framework discussion.  There are use cases in a conference where you want to
send the same source twice. 10:52 Jonathan:  You need to either have multiple
MIDs for a source or SSRC rewriting to get that use case to work. 10:53 Miguel:
 Bottlenecks are in the browser side.  I agree with Emil.  Nowadays we need to
rewrite SSRC. 10:54 Miguel:  Why must SSRC be immutable?  I do not understand
why. 10:54 Roni Even:  This is more than just a topology discussion. 10:54 Roni
Even:  You prefer that middle box is smarter because you cannot depend on the
endpoint.  I think that is the right way to go. 10:56 Roni Even: If we say
middle box is not trusted for what it will distribute then I understand why you
are doing this. 10:56 Paul:   You will get original SSRC value. 10:56 Paul: 
You still get original sequence number value. 10:57 Paul:  How does endpoint
react to that?  Does it use original value or modified one? 10:58 Richard: 
Summarizes tradeoffs. 10:58 Cullen:  Some issues around collisions. Lorenzo
Miniero 10:59 hummm for relaxing Simon Pietro Romano 10:59 hummmmm Bernard
Aboba 10:59 Richard;  If you are in favor of keeping requirement for
immutability, please hum. Simon Pietro Romano 10:59 ...relaxing Bernard Aboba
10:59 If you are in favor or relaxing, please hum. 10:59 We do not have
consensus right now. 10:59 Richard: We will take it to the list. Maire Reavy
10:59 relaxing Bernard Aboba 11:00 Cullen:  Emil should write a draft. 11:00
Richard:  Emil, are you willing to do the work? 11:00 Emil: Are you asking me
to define PERC with SSRC mutablity? 11:01 Richard:  What are the processing
rules? 11:01 Cullen:  All the things we need to put into various documents to
make this work. 11:01 Deb Cooley left the room. Bernard Aboba 11:02 Emil: I
have addressed the security concerns. 11:02 Richard: We need to wrap this up.
11:03 Roni:  You have to do the same for SSRC as for sequence number. 11:03
Colin:  Would be useful to produce a draft that lists the concerns. 11:03
Richard:  Are you volunteering? 11:03 Colin: No. 11:04 Cullen presenting
draft-ietf-perc-double 11:05 We have a hand wavy part of the draft.  The mixer
can insert some header extensions... but others we might not allow. Sean Turner
11:06 please use mic Bernard Aboba 11:06 Cullen:  Client will insert
client-mixer level.  Do you want MDD to copy values. 11:06 Jonathan:  It isn't
mixing, so no. 11:07 Jonathan:  MID is required for this to work. 11:07 Cullen:
 CVO does not make sense for middle box to change, coupled to original video.
11:08 Randell Jesup [1317443580@tiergarten.conf.meetecho.com/MeetechoWebLite]
entered the room. 11:08 Suhas Nandakumar left the room. Bernard Aboba 11:09
Clue Capture ID is in YES category 11:09 Emil:  Abs-send-time 11:09 Peter
Thatcher:  Why do you need MID? 11:10 Jonathan:  MIDs are chosen by the
offerer. 11:10 Peter:  congestion control stuff. 11:11 Ben Campbell left the
room. 11:11 Ben Campbell [ben@nostrum.com/avalon-air] entered the room. Bernard
Aboba 11:11 Jonathan:  No E2E confidentiality of header extensions.... because
I designed that so badly. 11:12 Cullen:  We can reconstruct the headers that
the original person sent. 11:12 Richrard: YES means mixer is allowed to change
it. 11:12 Harald:  Is there an extension for which there is a security concern?
11:13 Cullen:  Didn't look like it to us.... 11:13 Ben Campbell left the room.
Bernard Aboba 11:13 Roni:  Client-Mixer (Mixer needs to see it, but shouldn't
change the value). 11:13 Cullen:  Endpoint shouldn't be using it, so what is
the problem? 11:13 Ben Campbell [ben@nostrum.com/avalon-air] entered the room.
Bernard Aboba 11:15 Cullen:  Any other issues? 11:15 Jonathan Lennox:  I think
in Emil's architecture if you rewrite SSRCs, you will need to rewrite
timestamps. 11:15 Cullen:  Changes to this draft are minimal to support Emil's
plan. 11:16 sftcd [sftcd@jabber.org/18f2775dae1febea] entered the room. 11:16
Kathleen Moriarty [kathleen.moriarty.ietf@gmail.com/AdiumFFD0CA25] entered the
room. Bernard Aboba 11:17 Paul Jones, presenting draft-jones-perc-dtls-tunnel
11:17 sftcd left the room. 11:17 Kathleen Moriarty left the room. Bernard Aboba
11:17 Paul:  Using DTLS presents NAT/FW traversal challenges. 11:18 Paul:
Current protocol coupled to messages changing in DTLS 1.3. 11:18 Paul:  A TLS
or WebRTC data channel could address the above concerns. 11:21 Paul; 
suboptions for data channels 11:22 EKR:  Why are we not using the web? 11:23
EKR:  You seem to be assuming that DTLS packets being tunneled are going over
same channel as control info to MDD.  Why? 11:25 Paul: Coupling DTLS/SRTP with
control traffic.  There is convenience in that. 11:25 EKR: You could use HTTP
REST for the control channel.  Would make system much easier. 11:29 Richard: 
Not clear to me that passing transport messages via HTTP makes sense. 11:31
EKR: Web services interface. 11:31 EKR:  Messages 2 and 3, use REST. 11:32
bergtau left the room. Bernard Aboba 11:32 Cullen: Having two protocols could
create issues when load balancing sends the protocols to different
destinations. 11:36 bergtau
[bergtau@jabber.de/612cacd0-c1e3-499f-b572-bf0f652a2e6a] entered the room.
11:38 Yana Stamcheva [_1932356384@tiergarten.conf.meetecho.com/MeetechoWebLite]
entered the room. Bernard Aboba 11:39 Cullen on draft-ietf-perc-srtp-ekt-diet
11:41 Cullen:  There are legacy EKT implementations... but not clear we have to
worry about conflicting with them. Jonathan Lennox 11:43 Me, off-mic: do you
need a registry? 11:43 Ben Campbell left the room. 11:43 Ben Campbell
[ben@nostrum.com/avalon-air] entered the room. 11:45 Lorenzo Miniero left the
room. 11:45 Bernard Aboba left the room. 11:45 Maire Reavy left the room. 11:45
Nils Ohlmeier left the room.