Subject: [Simple] Draft Minutes from SIMPLE@IETF81

From: Ben Campbell <[email-masked]>
Date: Fri, 5 Aug 2011 15:19:37 -0500

The following are draft minutes from the SIMPLE meeting in Quebec. Please send any corrections as soon as possible.

Thanks!

Ben.

-----------------------------------------------------------------------------------------------------

[DRAFT] 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 middleboxes. 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

---

From: Eric Burger <[email-masked]>
Date: Fri, 5 Aug 2011 16:44:08 -0400

inline

On Aug 5, 2011, at 4:19 PM, Ben Campbell wrote:
[snip]
> is about to overcome a failure in middleboxes. And it makes

s/overcome a failure in middleboxes/overcome a failure in MSRP/

> Ben Campbell: 3GPP can make requirements for middleboxes. 
[snip]

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 8 Aug 2011 09:28:56 +0200

> The following are draft minutes from the SIMPLE meeting in Quebec. Please send any corrections as soon as possible.

Looks like the session was recorded, right? If so, can someone point em to the audio file?

Thanks!

--
Saúl Ibarra Corretgé
AG Projects

---

From: Ben Campbell <[email-masked]>
Date: Tue, 9 Aug 2011 16:02:48 -0500

> Looks like the session was recorded, right? If so, can someone point em to the audio file?

https://www.ietf.org/audio/ietf81/ietf81-204b-20110729-1256-pm.mp3 . That's for the whole afternoon. The SIMPLE meeting starts at about 1:19

Thanks!

Ben.

> Thanks!
> 
> --
> Saúl Ibarra Corretgé
> AG Projects
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple