Minutes - SIMPLE IETF 81 - Friday 29 July 2011 - Quebec, QC, CA Summary: -- Status: Only 3 remaining work items: draft-ietf-simple-chat, draft-ietf-simple-simple, draft-ietf-simple-msrp-sessmatch. We expect to pubreq the chat draft soon. Simple-simple is waiting completion of the other drafts, but should finish quickly. Msrp-sessmatch to be discussed in this meeting. -- draft-ietf-simple-msrp-sessmatch Christer presented changes. The latest version is a significant departure from previous versions. The primary changes (use of C and M lines rather than MSRP URI for connection management) appear to have support on the list and in the room. Eric Burger and Christer Holmberg will spin a new revisions, which will be followed by a WGLC. The AD suggested changing the draft name to reflect the new approach. The chairs will encourage people who have expressed issues with previous revisions to speak up quickly if they still have issues with the new version. Raw notes follow: Notes from Christian Schmidt: ------------------------------------------ IETF 81 Quebec, 23.-29. 07.2011 Fr 28.07.2011, 14:15-15:15 SIMPLE Chairs: Ben Campbell Minutes taken by Christian Schmidt Three remaining work items for SIMPLE: - draft-ietf-simple-chat-09, ready for publication request? - draft-ietf-simple-msrp-sessmatch-13, discussion today - draft-ietf-simple-simple-06, WGLC done without feedback, expired Christer Holmberg presented updates of draft-ietf-simple-msrp-sessmatch-13.txt. Main advantage, it works with TLS name based authentication. Eric Burger: Is there a reason to include topology hiding in the draft? Christer Holmberg: Not meant to be included in the draft, only reflecting mail-discussions. Christer Holmberg: Do we need to mandate usage of TLS when communication with middleboxes? Proposal: When CEMA Uas communicate, they MUST use TLS for MSRP. Ben Campbell: RFC4976 requires TLS between relay and endpoint. It is not required between relays. Hadrial Kaplan: It is somehow requiring SRTP, which is a much bigger hurdle. Ben Campbell: The TLS requirement could be problematic. Hadrial Kaplan: TLS would not work in this situation. Christer Holmberg: Perhaps we do not mandate TLS, but we can make strong recommendations to use. Ben Campbell (Individual): Just reference to security considerations in RFC4976. Perhaps a hint to use finger prints would be useful. We should not mandate TLS. Ben Campbell (Individual): I want to see a table, when middlebox have to be B2BUA. I am worried about complexity for middleboxes. Christer Holmberg: We do not request new functionality for middlebox. They just decide functionality according the CEMA paramater. Ben Campbell: If this approach is similar complex as RFC4976, then this makes no sense. Christer Holmberg: If this would be the case, I would make the same statement, but that is not the case. Eric Burger: This is not about making things easier for middleboxes. It is about to overcome a failure in MSRP. And it makes implementations for middleboxes much simpler. I am willing to spend a small increse of complexity now for this purpose. Ben Campbell: Keep in mind, we make no normative statements, how middleboxes work. We can not force middleboxes to implement MSRP B2BUA. Eric Burger: This is the reason, why this draft is important. Ben Campbell: 3GPP can make requirements for middleboxes. Hadrial Kaplan: Start WGLC Ben Campbell: Likely we will have this, but people with fundamental concerns are currently in SPLICES. Gonzalo Camarillo: Anything decided here will be backuped by mailing list anyway. This conflict was not to avoid. Ben Campbell: Sometime very soon, we will summarize on the list, what we are thinking. Then we will go to WGLC. Gonzalo Camarillo: I have officially the token. I would like to see a WGLC for this document. Perhaps a new filename would be a good idea. Andrew Allen: People could listen to the audio file of this session for preparation. Ben Campbell: We have done. ------------------------------------------ Notes from Martin Thomson: ------------------------------------ [Note: BC = Ben Campbell, HK = Hadriel Kaplan, EB = Eric Burger, AD = Gonzalo Camarillo (Area Director), AA = Andrew Allen ] Agenda: Christer on CEMA (Short aside noting that the WG is almost done) Review of (big) changes to the draft with CEMA Discussion on potential erratum on 4976: where the c/m-line is assumed to include the address of the UA (not the relay) On topology hiding: how many SBCs need to look at or change the MSRP messages? HK: None identified. EB: suggests that being silent on topology hiding might be good. BC: Agrees, operators will find other reasons to use B2BUA. On mandatory TLS: BC: 4976 requires TLS between UA and relay, which includes crypto and authent. HK: TLS is going end to end. BC: more secure. HK: but there wont be certs EB: you know about the presence of intermediary when you use TLS HK: not true, even with certs this depends on the SIP layer, you might be told to go to evil.com and if evil.com has a cert, then you think its OK HK: TCP splicing is commonly used, but that doesn't work with TLS because both peers think that they are the client EB: the certificate problem seems insurmountable BC: suggests referencing 4975 security considerations, but the fingerprint stuff in there might cause problems Conclusion: won't require TLS, will try to strongly encourage it EB: I'm not happy, make me happen Martin [Dolly] Editorial discussion regarding DNS names and IP addresses in a=path, etc... Asking for WGLC BC: Need to be able to describe when the middlebox needs to be a B2BUA. (?Need to describe how a CEMA UA can interact with a non-CEMA UA.) EB: this is not about making middleboxes easier. This is about fixing/working around the fatal flaw where signaling gets into payloads. The benefit for simpler middleboxes is a secondary benefit. Looking for a utopian ideal where there is nothing like signaling in the payload and there is a cryptographic assurance that the media is being exchanged with the expected peer BC: EB, you gave me heartburn. We can't make statements about middleboxes, but we need to make the things that people really do possible (mentions OMA). Nothing we do should depend on having middlebox developers heed our advice. EB: Yes. [[some clear, concise and evocative argument.]] BC: Agrees. BC: Unless we secure this all the way down, we have no security. TLS doesn't help, even if we can get certs, but this depends on the security on the signaling channel. And by definition, the signaling is not secure end to end because we rely on middleboxes mucking with the SDP. EB: -11 was insidious. End-to-end relies on trust with the intermediaries. -11 assumed that the signaling and MSRP went through the very same box. There was a chance of knowing that signaling was altered, but not media. HK: agrees with BC on premise. SAS option from DTLS-SRTP could be used in the future here. EB: does this help us get there? HK: yes EB: baby steps are OK BC: this is based on a model like the HTTP proxy, but it's now more of a policy enforcement point HK: yes, but it shouldn't be; if I want to enforce policy, I will B2BUA BC: if a middlebox chooses to be a B2BUA, you can't find out if they don't want you to On WGLC: *Chair: we will likely go to WGLC once the draft is reviewed, but there is a concern that some of the people in splices have big concerns about this, we don't want to get blindsided later *AD: we will have to confirm this on the mailing list Chair: will encourage haters to hate fast EB: how can you be against there being more security on the internet? *Chair: soon EB: proposes one more spin *AD: expects that this is more like a new work item going through the draft - following the normal process AA: suggests that those outside the group are pointed at the MP3 stream