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

PERC 94

0900 - 0915 Administrivia
Presenter: Adam Roach
Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-perc-1.pdf

slide 1: Title

Adam - Richard couldn't attend because of another wg presentation.

slide 2: Note Well

slide 3: Administrative Tasks

Jabber Scribe: Jonathan Lennox
Note Taker: Jean Mahoney

slide 4: Milestones

Suhas - No docs adopted by wg. New draft submitted since 93.

slide 5: Richard

Adam - couple of design team calls with results in the drafts.

slide 6: Agenda

ekr - why are we doing requirements after protocols?

Suhas - requirements haven't been updated, but will be summarized later.

----------------------------------------------------------
0915 - 1000 RTP Field Considerations
Presenter: Magnus Westerlund
Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-perc-2.pdf
Draft: draft-westerlund-perc-rtp-field-considerations

slide 1: Title

slide 2: Outline

slide 3: Methodology

slide 4: Usage Scenario

slide 5: Attackers

slide 6: RTP Fields

slide 7: Version (V)

ekr - Not sure what implicit means. Unless version 3 had a separate MAC at the
end. It should be integrity protected.

Magnus - yes. It doesn't cost anything to say it applies to version 2.

Jonathan - If you're muxing everything. You would hand it to your stun stack.

ekr - if it was version 3.

Jonathan - but the encryption would be same, that would be weird.

ekr - Rubric appears to be if the MDD doesn't need to modify it, protect it.

slide 8: Padding (P)

Cullen - agree up to e2e confidentiality. The point of SRTP was supposed to
expose some information to tools so that they could operate. They need to know
that the length isn't what's expected because it's been padded. This needs
integrity for sure. But not e2e confidentiality, we don't do it today. This is
the P bit, not that padding itself.

Magnus - My reasoning - if you an attacker knows that it's padded, the payload
is shorter. It gives you information.

Cullen - If you want that protection, don't use SRTP, use IPSec. I disagree
with this.

Colin - The only case we care about padding from the security standpoint is the
... audio case.

Magnus - It can be true for video. If you want to hide the media, events in it.
Everything becomes 640 bytes.

colin - the ... RFC recommends that all bytes are padded by one byte so the P
bit is always set and you can't infer anything from it. We don't need to worry
about it. If you are going to pad to hide the length, pad every packet.

Magnus - that should be in the doc. Then it doesn't need confidential
protection.

Colin - recap the model in which the MDD operates. Translator, mixer?

Magnus - Since we have confidentiality protected payloads, we can't do mixing.
3 topologies - transport translator, which changes nothing. SFM, and switching
media mixer, where the MDD forwards the source.

Colin - The assumption is that the MDD can't modify the content of the packet.
You can't modify the length of the packet.

Magnus - correct.

Roni - I don't think you need to protect Version. When saying e2e, it's not
e2e, it's to the next trusted entity.

Magnus - We need to discuss the trusted mixing entities we can have.

ekr - I'm a little confused. We have an existing SRTP design with assumption
that the people viewing the packets are hostile. And we are redesigning so that
the packets will be exposed to somebody who is partly trusted. The security
requirements are no stronger than the requirements for SRTP. Seems like you're
saying SRTP is not secure enough. We've expanded our scope.

Magnus - I don't think it's safe enough. You should be able to use other hbh
protection.

ekr - But this is e2e. My model of this is - you have a TLS tunnel to the MCU,
and that's protected against network attackers. And the MCU messes with the
srtp. This is a less dangerous situation than my SRTP going to you over the
network. If we want to strengthen SRTP we need to publish SRTP 2. Don't want to
create SRTP that's more secure for conference only.

Magnus - We use SRTP for hbh protection. Padding can leak information unless
you always set it. If you are going to pad, pad all the packets.

ekr - I thought we are talking about the srtp transform that goes e2e not hbh.

Magnus - yes, and the attacker is the MDD.

ekr - then we need to be concerned that the guy next to me can do that too in a
non-conferencing case.

Roni - we're trying to prevent the MDD looking at the media.

Magnus - the padding gives you a little bit of information to determine payload
length. Length matters.

Colin - the padding bit leaks some info. We already have a recommendation with
what to do with that in the ... case. Assume the same recommendation applies
here.

Magnus - agree.

Cullen - you agree that P bit doesn't need e2e confidential.

Magnus - agree.

slide 9: Extension Indicator bit (X)

Adam - we're 15 minutes into your presentation. Should we go through on a one
by one basis? We could do this on the list.

ekr - this is important. We're trying to build a protocol that's somewhat
weaker than SRTP, from the perspective of the MDD. I'm interested in the bits
that Magnus does not want to protect.

Cullen - Identifying that the bit needs to be modified is important.

Colin - are there no e2e header extensions?

Magnus - I'll come to that.

slide 10: CSRC Count (CC)

Magnus - skip this.

slide 11: Marker Bit (M)

Cullen - lots of codecs where it makes sense for the MDD to modify this - like
switching speakers. I don't see the attack to allow MDD to modify this. I see
little harm in the MDD setting this bit.

ekr - everything is in the authenticated SRTP

Patrick Linsky  - a truly paranoid client may not what to send ... if they
don't trust MDD. Having these optimizations available to the MDD to base
decisions on.  It will be useful for the ... case than to mandate true paranoia.

slide 12: Marker Bit (M)

Colin - It's how you manage SSRCs in the session. if you can see the SSRC,
speaker changes are obvious. This group should mandate to single way that the
middle box processes these fields. It will make life easier.

Magnus - I agree with that.

Adam from floor - I'm having a hard time understanding the harm. Need a
rationale that it's unchangeable.

Patrick Linsky - I share Adam's concern.

Mo Z - I'm nervous about the overall approach. This will affect operational
aspects of the MDD, and we're not thinking about future, 5 years down the road
when it's deployed. It may be senseless discussion. Let the MDD change
anything. If it does change it, indicate the original. Can authenticate
original fields from the sender. We don't have to get every bit right.

Magnus - don't agree. Need to know which fields need e2e confidentiality. Most
important.

Mo - what doesn't get it with SRTP now?

Jonathan - anything that's not confidential in SRTP doesn't need to be
confidential here, is not in scope. For authentication, the only threat I see
if an MDD could break up or consolidate frames, by clearing or setting the M
bit. If your decoder is robust that should just give frame or decode error.

Magnus - ...

colin - A marker bit is just a hint. I robust implementation doesn't believe
it. Not sure I agree with Mo. There are risks in revealing original SSRC if
it's been remapped, which would require careful handling not to break things.
We're focusing on the unimportant ones.

ekr - I quasi support Mo's position. I don't think Mo's base design will work.
The app would have to evaluate every single change as to whether it's
acceptable. It may be easier to have selective coverage and a delta mechanism.
In the future if we change our minds with complete MAC and cut outs. If we just
allow changes to a rule. I don't see getting around a list of things changeable
and not. Then we can design best encoding.

Mo - you're right - need informative text on what MDD should and shouldn't do,
but no normative text on MDD behavior. There won't be a universal rule about
MDD changing/ not changing bits. Some apps won't care. We should discuss which
header extensions need to be confidential.

Magnus - e2e context, there are cases unique to conferencing that are not in
the point-to-point SRTP.

Mo - not just point to point, current conference topologies.

Magnus - trust in all entities.

Mo - I thought we agreed that we didn't have to be more secure that SRTP for
the header fields.

Magnus - in multipoint cases - need to discuss those case. Your fully trusted
entity in the middle box - we need to move on.

slide 13: Payload Type (PT)

Colin - we are not changing SRTP. Go to what is different.

Magnus - go forward to an attack slide.

slide 14: PT Modification Attack

slide 15: Payload Type (PT)

slide 16: Sequence Number

slide 17: Replay Attack

slide 18: Delay Attack

ekr - this is a good example. This is introduced by allowing (deprotecting)
some SRTP fields. I'm concerned about this. Do you have a solution.

Magnus - unpleasant unfortunately. E2E reporting, and requirements on key
management system, When you know when the conference start.

ekr - the SRTP timestamp is covered by the integrity check.

Magnus - I'll come back to possible behavior. For the media mixing model, the
MDD needs to rewrite the timestamp. If you have the original from the source
you can base the protection on that, but you have to deal with clock skew.

ekr - the assumption for the attack is that the MDD can modify the sequence
number and the timestamps.

Magnus - definitely the sequence number. And you don't see everything - don't
know how many packets were sent when source was shut off.

Mo - this is already a problem for on-path attackers.

Magnus - no, it can't modify the timeline. It can only block or inject.

Mo - timestamp of the packet?

Magnus - The sequence number. Don't know how many packets.

Mo - if the receiver had info about the sender. If you have an intelligent MDD.
Provides buffered media if you join 10 seconds late. Shouldn't preclude those
use cases by prohibiting the MDD.

Magnus - Can change where media comes from or play out of sequence.

Colin - if you can change the sequence number you can have this attack. You can
mitigate it - you can disallow the MDD from changing it, or you can e2e protect
it. Problem - have to match the middlebox to how to protect the data. We have
to model the middle box better.

Cullen - I don't think this is possible by changing the timestamp and sequence
number, I would describe it it's possible by losing originals. If a router
delays, you look at the timestamps and sequence numbers to deal with it. Need
to preserve this info. On MDDs that modify sequence numbers or don't modify
sequence numbers, we have both and we have participants here that support both
kinds of models. We'll need to support them and more than a single model. You
solve this attack by not losing the original sequence number.

Magnus - The original sequence number is crucial to have.

John Mattson? from Ericsson - This attack is possible even if the MDD does not
change anything, it can still delay unless you have sync time from the
beginning.

ekr - anything that can be done by any network attacker in any SRTP system is a
WONT_FIX.

Colin - This attack is not possible in a normal SRTP system. You can delay
packets but the receiver will throw them away because the timestamp is out of
date.

Cullen - router can delay a packet just like an MDD and that packet will be
thrown away by a good implementation.

Magnus - Unless you have e2e protected RTP, the middle can lie about that part.

ekr - you say what the attacker can and can't do. we have two types of systems
- point-to-point and trusted media conferences. We are designing a new system -
untrusted centralized mixer with some new capabilities. Everything is an
attack. What new capabilities did you give that mixer so that it could attack?
Then we can talk about getting rid of that problem.

slide 19: Delay Attack

slide 20: Sequence Number

slide 21: Timestamp

Cullen - the receiver needs the original value or you can have a delay attack.

Magnus -

Cullen - SRTP detects delay attacks even if you don't use SRTC.

Magnus - you don't know what time has passed with stream off.

John Mattson? Ericsson - SRTP detects replay attacks if the packets have been
received earlier.

Magnus - The delay misses...

Cullen - they will detect packets that are too old and throw them out.

Magnus - jitter buffer. ...

Cullen - the jitter buffer drops them.

Magnus - if you get an original timestamp, how do you understand the timeline?

Cullen - you have a crypto ...

Adam - Magnus, you have 6 minutes left

Magnus - go to Splicing Attack

slide 22: SSRC

slide 23: Splicing Attack

Colin - I agree that's one protection. Some types of middle box need different
kinds of protection.

Mo - I think the attack is much harder than shown here. It's not just the SSRC
collision you have to work. There's the timestamp and sequence numbers. A
receiver would see it as a garbage stream with jumping timestamps and sequence
numbers.

Magnus - Turn off S1, turn on S2 and then turn it off. Goes back to delay
attack. Can fudge, because the receiver doesn't know the lapsed time.

Mo - this devolves into a delay attack. Splicing is the MDD's job.

Magnus - Need to know the original source. this is trying to pass one source
off as another.

Mo - the SSRC collision is the main attack here.

Magnus - yes.

Cullen - You don't want the MDD to lie about who the active speaker is. You
need to authenticate original source.

Colin - The attack isn't the SSRC Collision. It's the combination of the SSRC
collision and particular type of MDD behavior. If the sources are authenticated
e2e and the MDD is just passing streams through.

Magnus - No, it's malicious.

Colin - If the MDD cannot rewrite the SSRC, problem goes away.

Mo - I was assuming that there would be design to the original SSRCs to be
conveyed. The only way to have this attack was for SSRC collision to occur. And
the the timestamps and sequence numbers are close enough for receiver to accept
them.

John Mattson - you can do this on all topologies. The problem is inbound key
management ekt. Changing the key management is not the right solution.

Adam - closing - bring remaining issues to the list.

Magnus - please read draft and comment. Read the slides.

Rest of the slides skipped.

----------------------------------------------------------
1000 - 1030 Secure Real-time Transport Protocol (SRTP) for Cloud Services
Presenter: John Mattson
Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf
Draft: draft-mattsson-perc-srtp-cloud

slide 1: Title

slide 2: Complete Rewrite

slide 3: Terminology

Cullen - I mostly agree with this. If the conference app was downloaded from a
trusted source and verified. This is hard to solve. If you don't trust the
conference app, it can send the stream some place else, you are out of luck in
the webrtc model.

John - I'm not sure that you can't protect against that. We need to agree on
this model.

slide 4: Unique E2E SSRC (Sender Side)

slide 5: Unique E2E SSRC (Receiver Side)

slide 6: MDD Splicing Attack

Linsky - 1-1 mapping between SSRC and the client or that SSRC will not be
reused?

John - the client can have many SSRCs, but 2 clients can't have the same.

Colin - you're limited to what you can GW to. This is a closed system. GW to
legacy conference.

John - we have a trusted node that can assign SSRCs or ranges. Everything
behind the GW is out of scope and the GW is the endpoint.

Magnus - GW is a trusted endpoint. You don't have secure conference. Bad to
have that type of node

Linsky - We can't avoid GWs. There are just ends.

Cullen - You're not being responsible for what happens after it hits the
speakers. doesn't matter.

Mo - I agree with your first req. Need to make it cover SSRCs in general.
There's just one SSRC space.

Adam - the mixer would have to go to the kmf to SSRCs?

Mo - I don't agree that the solution falls out from those requirements. The
SSRC is a self-generated. If it's self assigned you don't need a 32-bit space.
You have 32 bit space because it's a distribute self assign and it seems
strange to force distributed self-assigned onto a centralized architecture.

John - It's the requirement that's important. The solution is a sketch.

Mo - if there are other solutions to mitigate splicing attacks, that's fine.

John  - yes.

Linsky - There's a different threat model with clients choosing random SSRCs.
two threat models: Clients trying to play SSRC games. The other is middleboxes.
We should treat those independently.

Jonathan - if you want global SSRCs, you need to guarantee that. Can't have the
MMD to do collision detection, it's not trusted to do that. The KDF could. It
seems complicated to design.

John - we can't rely on MDD.

Cullen - why doesn't random assignment work for less than 1000 participants?

John - We have 128 bit security everywhere else.

Cullen - You're confusing 128-bit security.

John - I think that it should be protected with crypto.

Cullen - why?

John - the kdf can detect collisions.

Cullen - If it doesn't, you'll still be able to tell collisions. Each will have
its own crypto context.

John - I don't think I have seen that.

Magnus - There's an assumption of detecting a higher-level identity. The
endpoint stream identifier, how do you know the collision has occurred.

Cullen - when you try to authenticate the packet and get 2 keys with same SSRC,
you have a collision. Rekey is separate, you get a rekey telling you the new
key. Let's read the EKT draft. Rekey is just anyone telling you to change your
key at any point without knowing the previous stuff sounds bad to me.

Mo - we can protect against the splicing attack. The MDD can force the
collision at will. 64000 byes to the endpoints until it hits a collision. The
timestamp and sequence number - those won't align. That's 96 bits that would
have to align and the receiver not detect. If you provide originals on
timestamp and sequence number, receiver can determine if the change is
acceptable. It's a huge collision space that's not worth protecting against.
You don't need to go to a centralized function to get your identifiers.

John - I'm skeptical.

Magnus - 96 bits may not be sufficient. If you have one source and keep it on
the side. It doesn't learn about the other sources colliding. You can splice
something that is older. It's a combo of delay and splicing. Need protection
against that. Longer the conference goes on, more chances you have.

Mo - this is just splicing. If the splicing attack devolves into the delay
attack this still doesn't solve it.

Magnus - This solves it. You can't get the colliding SSRCs you can't splice
into the stream.

Mo - Even without the colliding SSRCs, just delaying is an attack. Splicing is
a spoofing attack.

Magnus - Yes. There's less protection than you think. If you save the data. And
the mDD takes older data.

Mo - you are talking about collision in a 80 bit space. SSRC, timestamp and
sequence number have to all align to splice without the receiver detecting.

Magnus - if you save data over time from one source that has the same SSRC that
you want to attack, then you can splice, it's a larger space.

Mo - agree you don't have to produce a collision in the instant the packets are
being sent. You have to create a collision over that 80 bit space. All you
could ever splice is that instance of collision.

Adam - 10 minutes left.

ekr - Back to Cullen's point, is the assumption using 1 key per conference or 1
per sender? If you are using 1 key per sender it won't work. If it's one key
per conference it will. Each person sends the same key to everybody. 2 designs:
You can impose the same key on each participant, they send and receive with the
same key. The other is each sender has a unique key, and everybody knows.

Magnus - This would be the second.

ekr - then this won't work.

John - everyone has the EKT key.

Magnus - the assumption is one common group key for protecting EKT messages.
And SSRCs using EKT to protect the media.

John - everyone agrees splicing attacks, delay attacks, and splicing/delay
attacks need to be protected against.

ekr - Agree. We're not protecting against participants trying to be other
people. The only way to do that is to have the MDD tell you who the
participants are. Or have signatures. We're protecting against the MDD telling
you one guy is someone else. 2 ways to protect against that - everyone have an
identifier, and they MAC their identifier, and the receiver verifies. The other
was is to have everyone have their own cryptographic key. The identifier is a
lookup key. Why are you assuming one common key, it doesn't have to be. If you
have a compelling reason for it.

John - we need assignment on the SSRC to tie end-to-end identifiers to the
usernames.

Roni - Isn't it the conference application that does that, on the earlier
slide? That's why I think it should be trusted.

John - it needs to be trusted.

Magnus - That's from the webrtc space. Read the webrtc requirements draft.
There's a third party conference app that you try to invoke in a secure space.

John - let's continue on ML.

slide 7: MDD Delayed Playout Attack

slide 8: Topology Reduction

Cullen - If we can get everyone to agree, would be great. I'm not opposed to
it. It simplifies the problem space.

John - you would have the e2e SSRC in the SSRC field and the timestamp in the
timestamp field.

Jonathan - need to understand the use cases for the other ones and satisfy them
with this.

Adam, to note taker -  this is the closest thing to a decision.

rest of the slides skipped.

----------------------------------------------------------
1030 - 1100 SRTP Double Encryption Procedures
Presenter: Cullen Jennings
Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-perc-4.pdf
Draft: draft-jennings-perc-double

01:29:26

slide 1: Title

slide 2: What I want to talk about

slide 3: Problem

slide 4: The Double Solution

Ekr - Packet comes into the MDD and it's SRTP twice. I remove the outer SRTP,
and screw with the SRTP in the inner packet, breaking the integrity check. Then
I add a header extension that has the original values that I messed with.

Cullen - Exactly. So that your screwing with it can be reversed.

ekr - Then I SRTPize it with the hbh key. The receiver deSRTPizes it, validates
it against a list of things that can't change.

Cullen - Exactly but there's not a way to list the things that can't change.

ekr - if you have a TLS connection at the hbh layer, you could do a delta
instead. Receiver needs to validate that it's integrity protected.

Cullen - we need a way to insert the delta.

ekr - you can not modify the packet and add an extension that has new values.
Why did you do it this way?

Cullen - We have original and the new values. One goes in the existing spot the
other in the SRTP header fields. The way to think about this - when you encrypt
RTP, you get SRTP but it's still valid RTP. You want it to correspond to RTP
transport link you are currently on, which is hbh information. A firewall would
consider it a valid RTP flow.

Justin - the receiver take the TLV that carries the mods, ... when it computes
the MAC it verifies properly. Is that correct?

Cullen - Yes, the receiver would do the hbh encryption just like it does today.
Check that that worked, then it would take the TLV, replay the changes to
construct the original packet and feed it into what it does today to validate
it.

Justin - it's encrypted and MAC'ed just like regular SRTP but twice.

Cullen - exactly.

ekr - From an implementation perspective this is an inferior design. Not having
a reconstruction phase would be better.

Cullen - we would want to take e2e stuff and encapsulate it in hop-by-hop stuff.

ekr - If you were doing a gtls link between everybody and the MDD and I put
SRTP over that, but here are new values are using, I would put the original
value unmodified then put the delta.

Cullen - We could do that. One of the designs I considered was instead of tlv
encoded header extension. You put at the beginning of payload the original RTP
block. It would look like what you are suggesting. They are the same thing.

Patrick Linsky - you are using double twice here. Once is SRTP inside and
outside the envelope. The other is when the receiver undoes and makes sure it
looks good in the past. First double is good. The second double, what happens
if there's another MDD. multiple transformations happen along the chain. Maybe
you can ignore them. The MDD can set the previous value to the original value.

Cullen - I cover that in the draft, and it's as you suggest.

Roni - what would the new conference roster show in this case.

Cullen - Anyway you do this, there's 2 SSRCs floating around - hbh and e2e. The
endpoint needs to use the crypto context of the e2e scenario to decide you the
speaker is and bind to the roster information, which is out of scope.

Colin - you're doing this twice and storing the original packets leads to
conflicts with SSRCs and identity, things get rewritten. Two end points use the
same SSRC, which then gets rewritten by the MDD but then you provide the
original values. . ....

Cullen - 2 options: MDD can't change the SSRC, which makes all these problems
go away. If there are two, you'll need to know which one the packet is from.

Colin - there are 2 senders using same SSRC getting remapped my MDD/

Cullen - I'm fine with the requirement that the SSRCs need to be unique. Don't
need to be assignment to achieve that.

Colin - You need to specify the SSRC uniqueness requirement.

Cullen - The draft should list that. The ones are part of the SRTP crypto
context are the ones to get right.

John - SRTP transform is encryption with a single key. DTLS SRTP protection
profile...

Cullen - SRTP defines transforms that takes a key. I'm defining a new transform
that takes a single key. You take the first half of the key and you pass it to
an existing transform. You take the second half of the key and pass it to a
second transform. They both produce tag values that chain together and are
twice as long as the base transforms and they end up with a key that's twice as
long. From the syntax how you pass it around and insert it into an SRTP
library. If you are passing the key in SDES, which is not a useful use case,
the SDP would stay the same and it wouldn't look like two keys. It would look
like one long key and a single transform.

John - The concept of combining the untrusted hbh key with the trusted e2e key
seems extremely ... but the focus is on the RTP.

slide 5: One usage Scenario

Cullen - ...You talk to a trusted KMF, it would have e2e key and you would talk
to the EKT to get the hbh key. Out of band, the hbh key is revealed to the MDD.
It doesn't really matter.

slide 6: HBH: SRTP or not SRTP

Cullen - There are two transforms, you can use either. if you wanted to use
DTLS or IPSec for hbh, can use the same scheme and define a null transform for
the Hbh. You still need to encode and include the deltas.

slide 7: Pros / Cons

Cullen - I don't want to define a new protocol. This solution is simple. Is
this the direction we should be going?

ekr - you buried the lead a bit. You have secure channel, SRTP or something
else, to the MDD. The MDD sends a modified SRTP packet with a list that you put
back together again. I'm tentatively in favor of this. It's a mistake to think
of this as one mechanism. It's better to think of this as nesting. DTLS-SRTP
may not be up to handling the combined transform and we may need to define the
transform. This has identical comsec properties to what we've already debates,
but not identical security properties. We just need to decide what can be
edited. We don't have to decide how to partially MAC things. this will harder
to implement than selective MAC, but easier protocol design.

Colin - We need to be clear on what the middle box can do.

Cullen - Agree

Colin - We can't make this decision in isolation from what the middle box can
do.

Cullen - We need to decide that before analyze security properties but don't
see how it impacts basic structure.

Colin - Need to do them together. Like the SSRC collisions and the attacks, I
think the different approaches in the transport, the mitigation is different.

Adam, from floor - the difference between this and the other stuff - if we do
it this way, it doesn't close the door if we screw something up.

Cullen - dealing with header extensions could be complicated. This can deal
with fec.

Magnus - I see some need for e2e header extensions for authentication and
confidentiality protection. I'm not sure how that fits in this scheme. How to
apply e2e header extension protection.

Mo - We have some thoughts on that. Basic SRTP - everything has integrity, only
have to worry about confidentiality. If the endpoint put the confidential
extensions at the end with the payload, the inner transform could encrypt them
with the payload. The endpoint could insert that it made a change to the header
and length. It tells the middlebox that the length changed, the MDD won't know
what extensions were there.

Cullen - need to identify those header extensions.

Jonathan - Need to figure out if we need e2e authentication confidentiality of
RTCP and whether the same solution would apply.

Cullen - I was assuming it would. Need to delve into it and the draft doesn't
cover it yet.

Suhas, as chair - this presentation is not done, this is a -00 draft. Determine
What needs to be e2e, what can be modified. Do people think this is a good
direction?

Magnus - what are you referring.

Suhas - Cullen's proposal.

Magnus - I think it's premature.

ekr - This seems like a good general direction. Whatever architecture you
follow, there are just 2 general solutions for it. One is selective MAC, the
other is having an edit list. It's an orthogonal question what needs to be
protected. What needs to be protected need to be MAC'ed or not MAC'ed.

Cullen - I'm happy to progress this as an individual draft. Someone want to
speak for selective MAC, I can put in the next version.

Mo - selective MAC is trivial, just having the pre-transform zeroing out the
ones that don't matter, echoing the ones that you've changed.

ekr - The advantage and disadvantage of this design is that it's verbose. If
you don't care about the values, then there far more information being encoded
here. If we had fixed list of what you could change, then you would have
compact encoding or no encoding. We would have a tiny code point, bit mask, or
nothing at all. Zero out the things you didn't trust. How to encode that is a
different story.

John - I think it's too early to decide. this draft is too new.

Colin - I think you can make both of these approaches work. Need to discuss
what modifications are allowed. That will impact what works best and impact
security properties. Need to understand what the MDDs can do and then pick what
works best with that.

Jonathan - decision between selective MAC and delta. We need deltas for
relevant fields and consistently across the board. We can figure out how to
encode deltas later.

Adam - needs discussion on list on two different approaches.

ACTION: Discuss on the ML the two different approaches

Cullen - Seems that room was agreeing that the MDD couldn't change SSRCs. If we
can verify that decision on the list. That would be strong progress.

Adam - I made sure that was in the notes and I will highlight it on the list.

ACTION: Verify on the list that MDD cannot change SSRCs.

ekr - you are going to record rough consensus on that?

Adam - I'm going to record that everyone in the room that spoke on it supported
it. We didn't take a hum.

ekr - I suggest a hum.

Adam - OK. Hum - Whether you believe the --?

ekr - I flushed out an objection.

Jonathan - I need to understand the use cases where people think you need to
switch SSRCs. People aren't here. If we can meet those use cases without
switching SSRCs, I'm happy but I know if we can.

Adam - which is why we take it to the list.

Steve Boscoe - same here. I need more time.

Ekr - I apologize for breaking your consensus call. I support what Cullen said
- we need to determine what can/can't be changed and how they can/can't be
changed. Maybe an interim meeting.

Adam - I propose a call to focus exclusively on that.

Richard Barnes - make it so.

ACTION: Set up an interim meeting to discuss what can and cannot be changed.

----------------------------------------------------------
1100 - 1115 Requirements
Presenter:  Paul Jones
Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-perc-3.pdf
Draft: draft-jones-perc-private-media-reqts

slide 1: Title

slide 2: Agenda

slide 3: Requirements in Markdown

slide 4: Proposed New Requirements (Set 1A)

John - The third point could be restated that the MDD shall not be able to
impersonate any trusted entities.

EKR - that's a reasonable requirement. The MDD alone shall not be able to do
that. That the MDD and one other entity have to cooperate. No endpoint can
impersonate another endpoint independently. My replacement of C - Neither the
MDD nor the endpoint acting alone shall be able to impersonate another
endpoint.  Point B - I don't understand.

Cullen - On C - I agree with ekr's rephrasing. On B - it's about relative delay
that needs to be detectable. I don't think we know how to prevent an MDD
delaying all packets by 300 ms. I don't think it's a requirement. If we want to
detect that one packet was delayed relative to other packets from that client,
that's something that corresponds to things better.

John - On C - the MDD should not be able to impersonate anyone. Third persons
should not be able to impersonate any semi-trusted or trusted entity.

ekr - absolutely.

Magnus - B - detect how long and require the endpoints to have synchronized
clocks. B is to provide protection against delay attacks. Malicious delay.

Cullen - we don't we have a deployable, usable secure time protocol. We can
describe what we could do if we had secure time protocol.

Colin - B is about delay attacks and should be phrased in terms of that. In
terms of solution, there are options if we require SRTP end to end, and from
the MDD.

slide 5: Proposed New Requirements (Set 1B)

ekr - These are premature. These are not security requirements, they are design
decisions.  I'm not sure I understand F. I'm a browser, so I'm monolithic. If
javascript can't extract the keys, I'm ok with that. To say that half the
browser can't access it, I'm not on board with it.

Cullen - I don't think we can write anything we don't know what it means. We
don't know what "store securely" means.

Colin - D is not realistic.

John - why would hbh and e2e layers need to be related in that way?

Colin - because of what changes you are allowed to make to SSRCs may depend on
how the MDD works and the hbh changes. If we put a requirement for unique
SSRCs, that's coupling between the layers.

Jonathan - it's trying to say that you can use DTLS for hbh and everything
should still work.

Cullen - why are we discussing what it means? It's a design decision, not a
requirement. It should be thrown out whether it's true or false.

slide 6: Proposed New Requirement G

ekr - I think this is right, but restate to to remove ... to sender and change
making to make. The MDD should not be able to inject packets. The MDD should
not be able to make one person appear like the other. Those are two separate
requirements.

Cullen - careful with what we mean by identity. A use case we want to support
is that the roster at the far end is displaying, Cullen Jennings is speaking.
When I hang up my cell phone and dial in with my browser, it continues to
display, Cullen Jennings is speaking.  Those will have different SSRCs. Using
the term identity is confusing.

ekr - I'm concerned about this exercise. This is to organize thoughts, not to
polish. Do we need this document to exist?

Mo - Useful to call out splicing attack and delay attack. Should protect
against those. Have requirements to say that and to describe the attack is good
enough.

Ben, as AD - What are the plan for the doc? Will it be published? If we won't
publish, no point in quibbling. Unless you can voice a reason to have it
published, don't. Use a wiki.

Paul - the requirements are shifting, wouldn't say there's convergence at this
point.

Martin - Describe the system that you have as you evolve it. Describe the
properties - good and bad. The MDD can change timestamps - provide a list of
consequences. Same with SSRCs. This might be a throwaway. Email to the list for
each point would be adequate.

Rest of slides skipped.

----------------------------------------------------------
1115 - 1130 Usage of CLUE with PERC
Presenter: Roni Even
Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-perc-0.pdf
Draft: draft-groves-perc-clue

slide 1: Title

slide 2: Introduction

slide 3: Basic CLUE Flow

slide 4: CLUE MCU Flow

slide 5: CLUE relation to PERC

slide 6: CLUE relation to PERC: issues 1

Adam from floor - The MDD is semi trusted and you're having it add its own
captures - that's problematic. Once it becomes a party to the conversation, it
becomes completely trusted.

Roni - A question of implementation, what does it mean to be trusted. Question
is what do you want to achieve. Originally you didn't want the MDD to look at
the media, you didn't say that the MDD couldn't encrypt media and put it into
the meeting.

Adam - Once it has that key, it becomes part of the conference, and subvert the
purpose of PERC.

Roni - I understand the solution will not allow that.

Magnus - The CLUE central entity might have to be trusted and have a controller
interface.  Split the trust boundary.

Roni - Any solution that does multipoint with an MDD will have the same issue.
You have a roster you have to have trust relation. The media is not available
to the central entity. It can only send it to trusted participants that have to
go someplace to be trusted.

John - if we have a need for trusted clue entity who does the work? Is PERC
expected to integrate a trusted MDD?

Roni - No. The clue channel is a signaling channel with the same limitation.
The clue entity would be limited since it would not have access to the media.
Can't do switching.

slide 7: CLUE relation to PERC: issues 2

slide 8: Potential CLUE updates

slide 9: Discussion

Steve Boscoe - I need a better architecture picture. Is the MDD the only
distribution device? Is there another distribution device that connects to the
MDD? Can the MDD decrypt the clue channel?

Roni - PERC with MDD only addresses media part, this is not in the scope of the
work. How will the clue entity work when the media is handled by an MDD.
There's an assumption that it's a distributed architecture and we don't talk
about key management.

Richard, as chair - we have a milestone to do some sort of integration with
clue. But the R in PERC is RTP. We would need to recharter. And we are out of
time.