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.