SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions Interim Meeting Thursday, May 29, 2003 Agenda Thursday May 29, 2003 0900-1130 Message Sessions 1130-1300 Lunch 1300-1400 Message Sessions 1400-1530 What is a Tuple 1530-1700 RPIDs 1700-1800 BINPIDF/Filtering/Partial Notification Friday May 30, 2003 0900-1130 Publish 1130-1300 Lunch 1300-1400 Publish 1400-1600 Data Manipulation Attendees: * Mary Barnes * Brian Stucker * Adam Roach * Robert Sparks * Jonathan Rosenberg * Ben Campbell * Keith Drage * Hisham Khartabil * Aki Niemi * Paul Kyzivat * Jon Peterson * Larry Brunet * Gary Kenward * Jim McEachern * Tom-PT Taylor * Joe Zebarth * David Gibson Audio Bridge: * Aziz Mohammed * Avshalom Houri * Brian Rosen * Rohan Mahy Message Sessions (Campbell) draft-ietf -simple-message-sessions-00.txt Slides have been posted to list. Changes since last version: * No connection sharing: * Only TCP binding in this doc (doesn't preclude, just doesn't bind) * Each session gets its own connection. * Single URL identifies the session * URI only needed in BIND and VISIT requests Soft Session State * BIND and VISIT now carry expiration times * Host device can shrink but not increase * LEAVE and RELEASE are eliminated. * BIND and VISIT must be refreshed. SDP changes * Use of comedia style direction attribute to determine which peer establishes the TCP connection. * Simplifies negotiating which peer hosts the session. * Use * in format list URL format change Changed 2 relay semantics: * Introduced idea of "visiting relay" * Visiting relay "proxies" the VISIT request * Inter-relay connection established at session setup Security Discussion: * MAY operate as a visiting relay. * Jonathan: why is this a MAY? * How does the client know something is a visting relay. * Ben: Can configure client such that they're only a hosting relay * Jonathan: would you configure to be a hosting relay and NOT a visiting relay. * Ben: you might have a setup whereby you don't need a VISITING relay. * Jonathan: you have 2 configurations * Ben: don't want to require someone to be a visiting relay if they're a hosting. network topology that doesn't allow inbound connections. You allow connections to hosting relay. * Jonathan: you should never see a VISIT request be rejected. * Ben: if you get a VISIT request to a URL that not's mine, want to be able to reject. * Adam: like a web proxy * Jonathan: a relay may proxy VISIT requests and don't want VISITs rejected because they have other problems (eg capacity). Conclusion: ensure that the clarifying text is there that it's not a per call decision; you're either configured to be a VISIT relay or NOT. Security: * Added MSRPS URL scheme * Added digest authentication definition * Removed MIKEY dependency for e2e Discussion: * Jonathan: Suggests the Baugher draft - SDP mechanism to define algorithms. Discussion of Open Issues: Issue: More than 2 relays? * Non-explicit design team requirement * But it may be easy to accomplish with current 2 relay semantics. Discussion: * Cullen had concerns but he wasn't at the meeting. * Ben: anything that munges contents such that it's no longer a relay isn't a relay (eg BBUA) . * Jonathan: only potential problem is that it's mis-configured and it can loop. * Suggests to not even mention the mechanism * Jon: would like to encourage the use of no more than 2 relays. * Keith: there had been a proposal in 3g for no relays. * Keith: Anonymization could increase the number. * Ben: this might require additional signaling work, but not additional relays. Could still do this with 2 relays. * Jonathan: might need 4 if you want to tunnel messaging back to home network. * Keith: the tunneling happens at a lower layer. * Ben: throughout the draft is text that says you can have 0, 1 or 2 relays. There is no text saying you need to check for more than 2 relays. Perhaps, need text overall that describes why having more than 2 is not desireable. * Jon: Is there anyone that thinks there is a need for more than 2 relays. * Avashalom; Does a visiting relay count as more than 2 relays? * Ben: Yes. * Avshalom: you would need 3 is one is the proxy. * Ben: Perhaps, there's a confusion in terms. There is no proxies in this draft. There is a visting relay. Proxy is used in the context of a visiting relay proxying the request. * Jonathan: Concern is that enterprises with multi-tier internal security policies, where you separate networks. Security policy may require relays on both perimeters. You'd need to proxy both the VISIT and the BIND. * Ben: the hosting relay should be as close as possible to the endpoint. * Jonathan: Relay for both incoming and outgoing in a certain region (eg marketing group), then another one at the edge of the entire enterprise. * Ben: can this be solved at lower layers. * Is concerned that this is a common situation; don't necessarily want to force the standard. * Ben: how about putting in architectural discussion on the up to 2 recommendation. Don't want relays added because they can. * Jonathan: the reason for 2 is that there is a single layer of security for an endpoint. Reality, you should have no more relays than security perimeters. * Ben: web proxies: are there multiple of these? * Jonathan: wouldn't be surprised. * Ben: typically, this is in the combining of business units. One firewall connection to other Bus and one firewall to the Internet. * Jonathan: need discussion of the limitation based on the security issues. The protocol should not break if there is more than 2. * Ben: if more than 2 needed, would want a separate draft. * Jonathan: Not clear that there are real problems if there are more than 2. * Jon: Not sure that we need to worry about that type of architecture. Internal security points may have different characteristics and policies than external. * Jonathan :Don't want to encourage it, but it shouldn't break. * Tom: timers and visiting relays. * Jon: don't want to legitimize these type of things. * Ben: this should be SHOULD NOT. * Jonathan: general rule of SHOULD or SHOULD NOT requires qualification. * Keith: what are the example scenarios for SHOULD and SHOULD NOT. * Paul: things that would break e2e security are not relays (eg something that would record) * Ben: not considering recording, thinking more in terms of translation. * Paul: There will be requirements for recording. * Ben: one reason for a relay could be an intercept point, thus each BU entity might have relays, thus this might increase number of relays. * Ben: shouldn't prevent building tap points. * Aki: traversing NATs/FWs is referenced, but there may be other reasons. * Ben: Yes, other reasons aren't spelled out. * Keith: Need to define what are NOT relays. * Ben: anything that means message is changed is not a relay. Anything that enforces policies or records. * Aki: a normal relay could also record. They're not mutually exclusive. Do we want the ability to do multiple connects? * Jonathan: TLS tunneled through proxy? * Ben: not spelled out. * Aki: HTTP allows both. * Jonathan: typically would want to tunnel TLS through this. Conclusion: General conclusion on this seemed to be to keep the current recommendation to 2. Another Open Issue not explicitly on the charts: in reference to early draft on congestion and other requirements for message sessions; if a relay is present, it must be explicitly obvious to both parties. Right now, it's not to the visiting party. It's obvious to the binding party. * Jon: maybe need to reconsider that as long as e2e sec requirements can be met. Had originally considered that relays break e2e. * Ben: Does this consider TLS? * Jonathan: Are you going to tunnel TLS e2e? * Ben: that's another open issue covered in another chart. Issue: Single Connections * Do we need a separate connection for each direction? Discussion: * Jonathan: one conversation could interfere with unrelated conversations. This is 2 parties already communication. * Tom: the issue is whether the time between the send and response gets too large. * Ben: example of sending a movie in contrast to a message to stop. * Paul: If you don't want file transfer to interfere with another transaction, then you setup 2 sessions. * Ben: Probably should add some text that multiple sessions can be used to manage this sort of thing. * Jon: using a new session to prevent Head of line blocking isn't problematic. * Ben: need a usage scenarios section (or draft). Conclusion: include some documentation on this (use another session in some scenarios is recommended) in a usage section. Issue: SDP format list * Current wording overloads format list to give both envelope and contents * Should envelope be specified some other way? Cullen suggests that we make the * semantics default operation. Discussion: * Jonathan: listing message CPIM first is the preferred format list, you specify what goes further down. * Paul: but this means someone can send this un-enveloped. * Ben: requirement where it's going to specific to CPIM. If there is a session with a CPIM gateway, there needs to be a way for it to tell you to envelope everything. * Jon: The problem is that there is no negotiation of message formats in general. * Tom: have a CPIM attribute; the only thing would be the stuff that goes in the envelope * Ben: there is still problems with other format types. * Adam: multipart signed would have a similar problem. * Paul: I want them signed and they must be cpim. * Ben: Order isn't priority, it's preference. * Jonathan: how is this different than 3264; this is similar to lockdown. Here we need to lockdown on multiple things. Currently, order on m-line is choice. You need the type to be the aggregation of the base type. * Jon: this should be a general CPIM extension. * Jonathan: we're negotiating CPIM, there's nothing in CPIM yet. The negotiation of types is not a message CPIM problem. It's a session setup problem. * Adam: what's in the m-line is what you're willing to accept at top level and then an attribute for the compound. * Ben: How do you deal with multiple? * Paul: you should be able to do this. * Adam: can't think of a scenario where you'd want to do that. * Jonathan: simcap stuff. Doesn't change m-line semantics (or in preference) for top-level. Lower layers is a capabilities question. * Tom: sdpng (response: in 2 years) * Hisham: can't you have top level and than an error response? * Ben: a low bandwidth device; want to be able to indicate (list of things that can accept and that's all that's allowed) * Adam: suggests the use of the Accept header (text/* meaning that you can accept any) * Ben: is it acceptable to use that and then 415 later. Spreading knowledge across multiple places. Where does the accept header go? * Adam: ignore accept header concept; */* in the SDP. * Aki: where do you draw the line between what the device can render versus what you're willing to accept. * Ben: it's what you're willing to accept. * Jon: envelope part is the issue (not the device capabilities) * Ben: 415 only needed when you're wildcarding. * Paul: if I start sending you something that you don't want and get 415. Can you stop mid-message? * Paul: this goes back to framing issue. * Adam: you setup another connection. * Robert: to stop, you just abandon a session. * Keith: this does imply you're going to start processing a message before you receive it all. * Paul: the problem with small devices is size; * Ben: do we need a way in SDP to put a size limit? * Paul: then you might not need to deal with this. * Robert: you'd still need a recovery mechanism. Discussion around not seeming to be able to reach a conclusion. Robert: We need something fairly close to WGLC or this (draft) needs to be stricken from charter, because we can't reach consensus. * Jonathan: there's a set of proposals. * Tom: seems to be 2 different problems (hierarchies and capabilities) * Ben: max length gets to framing. * Brian: rather than set all boundaries up front; do it in multiple steps. * Paul: Propose that change this such that formats on m-line at top level (outer layer of hierarchy), with no *. * Adam: you might not have enveloping at all. * Paul: decide the enveloping separately. * Ben: Should be able to agree on top level. * Jonathan: this is most consistent with existing SDP. * Ben: for any given entry in m-line, there's an attribute * Jon: would it ever be different what type of things once could accept in a multi-part mime vs CPIM? * Jonathan: don't see this would every matter for each type. * Hisham: you don't need a-line. * Ben: CPIM gateway would have a format list only CPIM. * Tom: it's not just text. * Ben: Do we need to separate CPIM from something else? A single leaf content list is good enough. * Robert: go from there. If you have a container inside CPIM, do you need to talk about what's inside that container. * Ben: this is the same as multiple top level. Can you put multipart in the 2^nd level? * A: Yes. * Robert: Example: message CPIM wrapped from Jon wrapped in his own CPIM wrapped message. * Jonathan: the 2^nd level is the types that I understand. If message CPIM is your outer wrapper, then clearly you can do it. Problem agreed as: A bunch of embedded types and need to be able to define one top level. * Ben: List of things I understand is a concatenation. * Paul: It's a constraint on the list of things I understand. * Aki: why not have accept header in VISIT. * Ben: the endpoint doesn't see the VISIT. Conclusion: As summarized by Jon: Next version of draft will include a new attribute for SDP (Jonathan suggests using SIMCAP) and the use of m-line. Issue: SDP M-line - port field o Draft says to ignore port field o Cannot really do this, as zero in the port implies rejecting the stream o Adam suggests picking a standard dummy value for normal usage, keeping the zero semantic Discussion: * Jonathan: previous discussions with Colin and Mark: include as an attribute any information needed to construct URI that's not in the port or c-line. * Ben: previous problem with URL with user part , but now have only one URL * Adam: what do you put in the M-line if you want to use SRV? * Jonathan: with BIND, you've already picked your server. That's not conveyed in SDP. * Ben: it's logically nice to have rules for resolving MSRP that is not context specific. * Jonathan: agree with BIND and not VISIT. * Ben: URI returned in BIND or locally, would have a port. * Jonathan: don't agree. For FW traversal, you're going to want to be able to VISIT out; are going to want a port. * Robert: had gotten pushback from IESG on using well known ports. * Jonathan: didn't want this for shim layers. This is like HTTP connects. * Ben: are you suggesting we don't need SRV. * Jonathan: There is a big difference between VISIT and BIND; VISIT isn't a URL at all . * Ben: then why would you need it on BIND at all? * Jonathan: need SRV for load balancing. * Ben: not forbidding SRV on a VISIT; can have a hosting RELAY with session state sharing. * Rat hole.......... Ben: Problem is: Right now all the info is in the URI and you don't need m-line; do we want to backtrack to using m-line? * Hisham: then relay would have to write something in m-line. * Jonathan: this is a similar problem as BBUAs; typically, you're doing the stuff at a lower layer. * Ben: it's no different logically whether it's in the URI or SDP. Would like to leave in URI, unless you change what a BIND does. It's easy for the endpoint; if it has to be deconstructed into SDP, then BIND should return a body containing the SDP. All or nothing sort of thing, which is back to the basic question of what to use for port. * Jonathan: Okay with this. Conclusion: did not reach a clear conclusion on the original issue of the port in the m-line - this was deferred to later issue discussion (Default Port) Issue: Message Framing * Currently, require message size in start line. * Requires sender to know size in advance * Does not allow sender to start sending before completion of message composition. Cullen suggests a "zero" value in the size field to indicate the message size is unknown, and the receive must scan for delimiters. Discussion: * Robert: Want layers that are message size agnostic and be able to deal with it. * Jonathan: abort issue was a bigger one. * Ben: streaming media is an example of when you wouldn't know the size. But, then you should use RTSP. Conclusion: Couldn't come to a good reason for not knowing the size, therefore no change. Issue: DNS Issues Issue 1: How do we choose an A RR when multiple returned? o Ted pointed us to RFC 1794, which seems to indicate we should them in the order returned. Discussion: * Ben: URI in the SDP if it has DNS at all, should be deterministic. * Jonathan: 3263 says to try them in the order they get them. * Adam: 1794 is a site local thing. It doesn't point them away from trying them in order. Conclusion: per RFC 1794 recommendation of choosing in the order returned. Issue 2: Do we need NAPTR to determine protocol? o Current draft assures protocol always determined prior to DNS queries. Discussion: * Jonathan: it would cause problems with SCTP later. * Keith: why is SCTP excluded? * Ben: didn't want to do work. * Jon: don't see that much advantage of SCTP over TCP with TLS. * Ben: skeptical of building the draft and excluding other transport protocols. * Jon: transport agnostic causes problems. Don't go out of the way to support these other things later. * Ben: the reason SCTP was excluded was a time to complete this draft. Conclusion: Not addressed in draft now, but URI should be extensible. Draft shouldn't restrict or preclude SCTP later (it's just currently out of scope). Side discussion on transport agnosticism. * Transport AD: it's bad; look at the SIP problems. * General: SCTP was looked at and it didn't solve all the problems. Authentication of VISIT Should we encourage digest auth of VISIT? * Include temp, single-use credentials in the session URL in SDP? Discussion of Cullens point: * Assuming SDP protected, if you include URL in visit that could be intercepted and be used later to hijack a session. * Would likely take the session down, because the real VISIT would fail, so the window is small. * Cullen had suggested a PW In the URI. Discussion: * Jonathan: the reason the window is small? * 1. the attacker has to sniff the VISIT request (assuming SDP protected). Attacker would have to generate own VISIT in short time * Robert: could do as a man in the middle. * Jonathan: similar to comedia problem where the session can successfully be setup with the attacker. * ... * Ben: If I INVITE you, I can say both; if you try to connect and succeed, then I host. * Paul: this is different from comedia; answerer doesn't respond both, it picks by trying. * Jonathan: this may help with comedia. * Jon: what security properties does this provide that can't be provided other ways? * Ben: TLS should be used (hop by hop or e2e to be determined). * Jon: there will be another CONNECT like proposal accepted; it introduces more security problems than it solves. TLS will likely be hop by hop. * Aki: you still have policy control. * Ben: it becomes impossible to put a policy enforcement point in a relay. * Jon: it makes the relay open. * Aki: if you have a reserved port for MSRP, then you could still tunnel. * .... * Ben: visiting relay may want to authenticate user. * Aki: suggests 2 messages; 1 auth and then 1 VISIT. * Ben: that's a separate issue. * Jonathan: it makes the common case more complicated. * Adam: what does that gain? * Jonathan: this doesn't seem to help. * Ben: suggesting that you don't need auth to a hosted relay, but you may want it for a visited relay. You could say that you don't need to auth in the visits, just define a separate method for visited relays for auth. Would you ever want to auth hosts? * Adam: it's not useful because you don't have realms. * Ben: you would need realms. Conclusion: No conclusion reached at this point (this was discussed later around the TLS specific issues around the discussion of the new method for visited relays for Auth) Issue: Digest Authentication Should we add Tr-ID and S-URI to hash? Conclusion: a good idea. Issue: MD5 vs SHA1 Discussion: * Jonathan: should be SHA1, MD5 is out of favor. Conclusion: SHA1 Issue: Do we need to handle multiple challenges to ... * Only makes sense for VISIT. * Do we need realms Discussion: * Jonathan: VISIT protocol is client to server; if the server decides it needs to auth, it may challenge the clinet. Conclusion: * 2 relay situation: VISIT: a challenge is always a challenge to a previous hop; challenges are not passed through relays. Challenge is invisible to endpoint. * Don't need realms. Issue (not on the charts): Discussion of another related issue around the need for challenges on different transaction identifiers. * Jonathan: there's 2 protocols: message transfer (end to end id) and connection management (hop by hop id). Propose 2 explicit header names. * Ben: Proposes a section on connection management and one on message transfer, thus don't need explicit headers as the context clarifies. Another Separate issue (not on the charts) as brought up by Aki : Do we need a response for the SEND? * Ben: If you don't have this, you have more reliablility issues (differences between timeouts and rejects). Which led to another Another separate point related to reliability: With a single session on a connection, do you need refreshes? o Adam proposes to rely on TCP keepalives. * Jonathan: proposing a ping-pong for keepalive (instead of softstate for refreshing). * Ben: with the SEND with a response, you have the equivalent of the ping-pong. * Adam: this means you have to send this periodically. * Paul: same semantics as keepalive. * Aki: ... * Ben: Either timer shuts down session. * Adam: nightmares back to session timer. * Aki: why do you have to negotiate a timer. * Ben: it's the relays that care. * Jonathan: why? The relay cares that if there's a failure it has to wait for someone to send a message to find out. Session timer problem was the negotiation. * Ben: thinks that refresh is okay ; ping pong only gets rid of hop by hop refreshes. Relay needs to still look at ping pong. * Jonathan: alternative is to suggest an end to end keepalive. Relay knows that if it doesn't see any messages the session is gone. * Ben: only benefit is that you don't need expiration on the BINDs. * Jonathan: additional benefit (of ping pong) is that client end to end knows, as well. * Brian: prefer expiration over ping pong. * Ben: unless a compelling reason for e2e ping pong is put forth, stick with refresh. * Jonathan: likes e2e. * Ben: this is a significant enough change that would need additional time for feedback (thus delaying draft). Conclusion: keep refresh. Final issue: needs expert security review. Conclusion: Ask Jon to ask Ekert (sp?). Issues around TLS usage Issue: How do we signal TLS usage? o Currently through MSRPS URL scheme o Currently use proto field to determine transport Propose: use MSRPS in URI, but proto field is MSRPS/TCP. Discussion: * Jonathan: If you were composing from SDP, then it's not useful. * Don't need MSRPS. Issue: Do we use _tls as protocol in SRV queries? If so, how do you specify actual transport protocol? o Since TLS support is required, is this needed at all? Discussion: * Jonathan: it's in the service field for 3263, * Ben: should use MSRPS and not TLS. Ben's proposal: Proposing the change to be to ask for TLS connect port and use service field of _msrps. Discussion: Jonathan: not getting a separate port for TLS, so there's a problem. Issue: Need to specify required cipher suites. * Jonathan: should be the same as SIP. Discussion/Conclusion: * Ben: need to discuss impacts of client certs (in peer to peer TLS) in the usage section. ****Make sure to discuss: Well known ports - TLS versus non-TLS on the port issue. Continued after lunch (Notetakers: Aki Niemi and Hisham Khartibil) . These weren't taken while I was official notetaker, but I thought might be useful to lend continuity to the overall Message Session discussion. However, I was not as conscientious about capturing conclusions, but I thought these might be a useful compliment to Aki's and Hisham's notes. Review of Lunch time issue discussions on MSRP: o Aki's proposal to use of SASL for security. o Jonathan: you'd still use TLS, but within TLS, use SASL for client authentication. SASL is useful if there are lots of authentication mechanisms. o Abstract sucks. Ø Will be updated. o Should MSRP and use of MSRP be in separate drafts? Discussion: o Previously SDP draft was separate from protocol. Currently, SDP negotiation is specific to this protocol. o Keith: if you look at the abstract, you have 2 separate scopes. Extensions to SDP and MSRP. o Jonathan: there is plenty of precedent for SDP attributes as part of the protocol using them. MSRP only works under the assumption that there are dependencies. Propose that doc would read better by re-ordering. Issue: CMS usage * Probably need to say more about how key material is transferred. * Do we need to say more about use of symmetric crypto in CMS? * CMS usage probably needs security expert review. Discussion: * Jonathan: suggests that this might be per SRTP keying. * Jonathan: Why is this CMS and not S/MIME? * Ben: does S/MIME have support for symmetric key? Cullen had volunteered to write some text around this. Action: Robert will find someone to follow-up on this. Issue: Scalability o Relay scalability is reduced to not allowing shared connections. o Primary scaling story is based on e2e usage. Does draft need to talk more about scalability issues and design approaches? Discussion: * Jonathan: look at http proxy model. * Ben: Connection sharing advantage is only for multiple relays. Issue: Default Port Do we need one? * Not really needed by protocol * Might be useful for firewall configuration. Discussion: * Cullen's point about a recommendation, but has no protocol significance. * Jonathan: that's still a default port. Assuming http style. * Cullen (per Ben): no port explicit, then you go thru SRV. * Ben: 2 halves to VISIT. Session URI should have an explicit port. If you don't have one, then do you do SRV? * Jonathan: don't think doing SRV will be useful. * Adam: propose to make it a should * Ben: thus it would still be possible to receive something without a port, thus SRV is needed. * Robert: multi-homed host situation might make the need to use SRV. Would need to be able to hand something back in the bind. Conclusion: make this a SHOULD use an IANA registered port. Back to a separate port for TLS issue (as noted above): . * Jonathan: the trend is to demux shim layers like this; have the appl deal with this. * Ben: All MSRP sessions must use TLS; why not mandate? * Paul: end to end, client to client, with no certs. * Ben: there's a work-around. But, agree can't absolutely mandate. * Aki: 2 ports are bad due to limitation on port #s. With 2 ports, you have possibility for attack. MSRP needs a way to tell the other way to start TLS; that should be the only way. * Robert: the use case is the BIND (not the VISIT). * Adam: if we're using the limitation of ports as an excuse, then any ports are bad. * Jonathan: there are firewalls. * Adam: we're doing relays to deal with FWs. * Ben: reduce the need for relays with the port. Agree that others are more restrictive - known ports and known devices. * Jonathan: it's okay to require a solution that's inline with existing practices. Otherwise, you need an explicit start TLS request. * Aki: then you need a whole security agreement structure around this. * Jonathan: make TLS a must for clients and servers to implement. * ..... * Jonathan: this should be like 3263. A case where the client got a non-TLS URI and the server wanted to insist on TLS. * Aki: why not one MSRP URI, such that it is configured to use TLS always. * Jonathan: the advantage of a MSRPS URI is that you would avoid a round trip. * Ben: in a 2 relay situation, you might use MSRP to VISITing relay, then you would have sent the info you wanted to protect in the clear. Propose that you can't use an MSRPS URI unless you've done an exchange to start TLS. * Robert: without exception, are requiring a separate transaction in the clear to start TLS. * Rohan: in SIP and HTTP, you use a separate port # for TLS. * Jon: having separate port #s is bad, the other path, however, is also problematic. SIPS approach is that you can tell whether it needs to be secure. It doesn't actually require separate ports. * Jonathan: how do you demux these? * Jon: you use the TLS messages. There is no reason why the demuxing can't be handled. * Rohan: why not always use TLS? * Jonathan: per previous discussion. Want to be able to speak a single protocol and know what to expect. * Jon: the complexity in looking for start TLS versus TLS hello is probably the same. * ..... * Jon: big concern about this upward negotiation - can't be a surrogate for MSRPS. * Ben: thought that the approach was that if you had an MSRPS to start with, the first thing you do is start TLS, then BIND. IF an MSRP URI, then you BIND first or a server could force you to start TLS first. * Jon: that might be okay if the client shuts down in the cases where TLS isn't started.... * Rohan: TLS as mandatory, the motivation against doing that was that debugging would be a pain. * Ben: the other reason is requiring TLS all the time could be a pain for the peer to peer case. Conclusion: need a new method for start TLS (reference RFC 2818) Continued discussion (Jon P): Not clear on IESG consensus that a separate port is bad. Security people don't have a problem. Discussion: * Ben: 2 port route is simpler. * General: should be able to sniff TLS hellos, rather than the new method. Adam to look into. * Robert: would be easier to spell this out, if there was an explicit request. Back to Message Sessions Backtracking to issues requiring feedback from Jon P: o SASL: o JonP: SASL is popular with appls, but it's not easy to plug into. It adds considerable expense. Digest is the current mechanism. It is useful if you're going to plug in another mechanism later. o Jonathan: the spec work isn't less with SASL. o Aki: thought that since Digest isn't being re-used, it's being rebuilt, then perhaps SASL might be preferable. o JonP: implementing SASL into the appl layer might be easier, although, if this is just to get Digest, then it's not worthwhile. But, would be worthwhile if were going to allow other mechanisms later. Conclusion: stick with digest. o CMS vs. S-MIME. o It's better for encryption than integrity. o Ben: still need resolution on the symmetric key thing. Conclusion: Just use S/MIME. Will also verify the ability to use symmetric keys in S/MIME. Issue: Discovering the need for relay * Cullen asks if we need a way to discover whether one is needed. * This was explicitly ruled out by the design team. ... * Should we allow discovery via SRV query (given that you know there is a relay), rather than requiring explicit configuration? Discussion: Adam: this sounds like device configuration. Ben: you might want to put informational text; not sure that you could use STUN for this. Conclusion: don't need to include this in the doc. Issues: Timers - do you need to specify? * Brian: need this to be optional. Should be able to turn off keepalive. * Adam: relays may want to reclaim state aggressively. (thus no default) * Brian: relay should be able to have say on the value. If relay is under heavy load, it should be able to adjust. * Ben: this is the same argument as SIP, where they thought about allowing registrar to increase. * Paul: Can relays initiate this? * Ben: right now, there is no place that a relay initiate a request. Relays need to know how to send keepalive send. * Robert: If endpoints don't care about a refresh, relays could set the expiration on a bind or a visit. * ... * Robert: propose if there is no Expires and relay doesn't want one, so it doesn't send a response requesting one. This leaves out the other party. Conclusion: fixed value; engineering exercise to determine optimum fixed value. Issue: IANA considerations * What needs to be registered? * SDP attributes * MSRP port Conclusion: agree with above Issue: Naming of BIND * Cullen suggested to change to LISTEN Conclusion: keep BIND Issue: Hosting requirements * Do we need must support requirements for various host scenarios? Discussion: Proposal that MUST be "both". Policy may impact role. * Jonathan: another issue why comedia doesn't do this. Would wait for TCP connection to fail before you could establish the session. * The other problem is you could end up with 2 sessions. * Paul: the problem with comedia is that you try both even though one is likely to succeed. * Jonathan: we have a punt suggestion that comedia doesn't because we have relays; answerer always initiates connection to offerer. * Ben: this brings back to the discovering if you need a relay. * Jonathan: this is back to the ICE problem; relay is less preferred. * Jon: if the best thing you can do is try, but trying gives the attacker the opportunity to emulate. * Ben: If I'm hosting locally, then attacker needs URI.