SIPSEC ad hoc meeting notes


Note-taking: Spencer Dawkins <spencer@mcsr-labs.org>

Cullen framing

We have an interesting problem, based on list review, but there's a lot to look at. Need to pick specific problems.

ICON for "secure phone call" - what does that mean? Some is "local policy". Encrypted media? Know who you're talking to? Knowing the person you dialed is the person who answered? Knowing no one snooped your signaling? Some binding between all these things - this is what the "hopping bunny" was about.

SIPS: URL does NOT mean ANY of these things.

What ciphers are acceptable?

Problems for SIP, AVT, MMUSIC...

Problems on TLS and SIPS: - bugs and unclarities, see Francois draft. May even have contradictions in specs, need to resolve confusion. A ton of people have "implemented" TLS and even SIPS: but not clear what works. "TLS across all the hops, or almost all, or anything..." Hard to define, retargeting, ... SIP goes one direction with retargeting, but SIPS: never thought about the other direction. Have to decide what we want to do. Have to be symmetric. "Secure" always TLS? See problems with IPsec...

Dean - current document problem - no way to know that all nodes complied to the spec in the middle.

Brian - we either transitively trusting or we aren't. We have to choose.

But we have requirements for end-to-end security, too.

Can we assume transitive trust?

Jon - if there's a SIPS URI that's signed, that's a comfort at the other end, but it's a small comfort.

Can we agree on transitive trust?

Simplifies scope but doesn't guarantee solution.

Jon - EKR suggested something like SIPS in the document, and this was late in the process, threat model pretty much worked out but SIPS inserted quickly (too quickly? and carelessly). Probably a number of problems to address.

draft-audet-sip-sips-guidelines-02

"At best underspecified" and probably wrong. Started 00 to explain how we were right ("we're the IETF"), and every version of the draft gets worse.

Need to make some decisions pretty soon. People are developing this now. Implementations don't have that much to do with 3261.

Vijay - specific problems - upgrade/downgrade, transport=tls (deprecated). Can be implemented, but there are problems.

Six sections in the draft - meaning of SIPS, upgrading/downgrading, SIPS registration, SIPS dialog, transport=tls, a lot of other issues (GRUU, outbound, REFER, background).

Meaning of SIPS - TLS for each hop until terminating domain.

Jonathan - intent is that last link is secure (somehow).

Biggest problem is that we're not symmetrical for reverse path - in-dialog requests cannot work.

Does not mean a Padlock icon, requires Record-Route or things get dangerous quickly with SIPS Contacts.

Jon - issue was assumption that UA would not be able to accept incoming TLS connections - and assume that the reverse path would work the same way ("secure in some sense").

"Support SIPS" is "support TLS connection to remote first-hop proxy".

The part that's broken is that people assume UAs don't have to support SIPS. They do, in order to make outgoing calls.

Dean - Proxy is SIPS/SIP converter (in Dean's remembered vision).

Record-Route and Contact interaction is not limited to SIPS.

Jon - once we have outbound, we're in a position to do this right.

Suggestions from list: deprecate SIPS altogether, deprecate last-hop exception (not sufficent alone), explain the exception and fix the bugs that result. Draft assumes third choice, but lots of people like deprecating last-hop exception. People liked deprecating SIPS, too... Need to accommodate 3GPP here.

Do people think we should deprecate SIPS? More chaos, people have implemented SIPS. Juha said "broken for now" note until we fix it - Francois' draft is that note :-)

Don't think SIPS works at all on a business card, or in to/from. Can't use a padlock hop-by-hop.

What does "deprecate" mean? Telling someone that SIPS will almost never work?

EKR - point of SIPS is to provide given level of security. Does it work? Problem is TLS ending at proxy.

Scott - "SIPS is broken"? Want to be able to say a particular connection must be made over TLS. Sometimes, that's the only thing that works. Need to be able to say "secure" about particular hops.

Jonathan - we have many documents with "use SIPS" as security considerations for relationships between proxies and clients. That is reasonably useful, even if it's not end-to-end, even if you need to trust middleboxes.

Francois - can't deprecate, too pervasive.

What do we expect to get out of SIPS? Need to know this to know if it's useful.

There is a real threat being solved, preventing people snooping or modifying requests.

This is everywhere in the document set. "Use SIPS" is the "use IPSEC" of SIP.

Don't need to change the meaning of SIPS in this group. Need to focus on the real problems - last-hop, explanation Jon gave at beginning of the meeting.

EKR - wouldn't it be great if we had end-to-end security, or even integrity? In SIP, like it or not, trust model is that proxies can screw you anyway they want. With that, SIPS is useful, but not for lock displays.

Scott - agree with EKR, start by explaining the meaning of SIPS. Clarify whether it's about signaling, and how far. Doesn't cover media (which is what people actually think about, and a totally different problem). I want TLS protection until I get to something with the certificate that matches the request URI. I understand semantics are different but think this needs to be clarified. Francois has made a start at this.

Options - deprecate SIPS, explain what SIPS means, allow transport=tls.

We have consensus that we will not deprecate SIPS.

Transport=tls was formally deprecated, but no one believes this and many/most implementations still understand and will use this.

Allows for "best effort" hop-by-hop TLS usage. Endpoints that cannot have a DNS entry can't have own certificates anyway.

(Also need to add a transport=tls-sctp (like Via) - would be more consistent, too)

Jon is confused here. how to start supporting TLS for one hop? But this isn't about SIPS right now, right? We'll table this now.

Some people infer "must use TLS on REGISTER", etc. from current documents.

Registration: AOR - SIP implies SIPS, this is a big problem since many, if not all, UAs cannot process SIPS URIs. New way to explicitly register SIP only?

If you only register SIPS, you haven't registered SIP - this is not symmetrical, either (more comfortable with upgrading than downgrading?) Is this broken? Not sure why we're indicating that you have only one or the other AOR...

Interaction with Outbound - create a TLS path to home proxy, so proxy can send either SIP or SIPS to you over TLS ) which is what you're asking for.

SIP and SIPS as separate registrations? Cullen - this would always work. Can we imply an upgrade path where one always implies the other? Which way?

Francois - not backward compatible. If you send SIPS to most clients you'll be in trouble. This is an AOR, right? It's equivalent to being a different user. Or at least using a different port.

Jon - great explanation by Jonathan but that's not in 3261 - Jonathan agrees, this is the way to move forward. "URIs are never equivalent" text does exist, but so does text that says both need to exist as aliases.

Francois - some people are thinking you should derive reachability from the transport you used for your registration.

EKR - SIPS means "TLS all the way somewhere". SIP means "maybe over TLS, maybe not", and can't expect people downstream to use TLS or it may not work.

Does it matter which AOR you use?

Jon - if you're registering a SIP URI, can't expect you'll be able to do SIPS.

Francois - if you don't use outbound, what does this mean?

Jon - use whatever channel you've got.

Francois - was assuming the opposite (SIPS would imply only SIPS, SIP would imply both).

Registration contacts - list explicitly all valid transports, using q-values?

Jonathan - clarifying 3261 without changing it, right? Pointless. Let's start over and do this requiring SIP outbound.

Jon - Outbound isn't done yet.

Jonathan - This is done first?

Proposal - write a standards-track document that fixes 3261 and requires outbound?

Keith - need to look closely at normative change process - do guidelines document PLUS fixing 3261 document.

Francois - need to agree on normative changes - then we can split.

Aki - I like SIP in contacts, to, from. With outbound, contact doesn't matter anyway. Don't put it in to/from/contact.

Paul - when do we get clarification? No one knows what it will take to fix this stuff (or at least not sure you're talking about the same thing).

Francois - don't pretend every statement in 3261 is correct.

Jonathan - we have 200 bugs in Bugzilla - why would we question this?

Jason - SIPS:transport=tcp?

Robert - what does that mean in a route header? TLS one hop away?

Scott - back to the current definition of how many hops you use TLS (until you reach the named destination domain).

Jonathan - have proposed change to location lookup - add route header. We screwed this up in 3261?

Scott - if you let UA register SIPS URI with non-SIPS contact, that's an explicit action on the part of the user.

Cullen - I think I agree here.

How to deal with Contacts in REGISTER, Record-route, contact in dialog...

Jon - hum on fixing 3261 instead of apologizing?

Francois - thought we were making a proposal to fix in next revision.

Next steps - to list.

Jon - need to know how this works with outbound in order to make recommedations.

draft-gurbani-sip-sipsec-00.txt

Do SIPS the way HTTPS works - end-to-end upgrade?

EKR - HTTPS blows through proxies, "get out of my way". Not what we're talking about now.

Cullen - if we didn't Record-Route, we'd get the same thing in SIP.

Cullen - Dean arguing for something that only works if there are no proxies. Interesting, scenario does exist,  but this isn't the main case. This is why we don't encrypt headers.

EKR - 18 proxies between point A and point B are there for a reason, not just forwarding packets.

We'll talk about this more on Friday afternoon (at P2P-SIP).

Vijay - we talked about this on the list, and there are people who want their proxies to stay involved.

Cullen - most of the proxy twiddlings are in 3261 as threats, and the answer was "use end-to-end security".

EKR - this creates a generic NAT traversal server mechanism. Once you're in TLS, go crazy. There's like one proxy between you and an HTTPS server.

draft-srivastava-sip-e2e-ciphersuites-00

Level of security is missing. SIPS is a mess. Should DTLS be considered as well?

Extend Via to include Ciphersuites, define header for desired cipher-suites, secure protocol, etc.

EKR has an alternative solution - let TLS take care of ciphersuites at each hop, rely on mandatory-to-implement as common-denominator, trust proxies for mandatory upgrade/downgrade.

Jonathan - with EKR on this one, proxies can do so many things that are worse.

SS thinking of catching evil proxies more quickly, allow UAC to control ciphersuite selection.

SIP Security advisor says there's a hole in this. Would Security ADs pass this document?

EKR - current security is worse, right?

Dean - this catches stupid proxies. Evil proxies lie.

EKR - in TLS, your client has no control over what the server actually chooses, right?

Proxies doing DTLS to TLS need to know ciphersuites for other protocols.

Open issues - which solution to pick? Partial adoption with SIPS? Impact of renegotiation of ciphersuites needs to be analyzed?

Has anyone else read the draft? 5 or 6. Anyone who might implement?

John - I thought so, not so sure now if we're trusting proxies.

Dean - need a mechanism for Proxy A and Proxy C to keep an eye on Proxy B - this could be it.

Discussions about SIP and TLS don't state problems and then argue about details, so never come to conclusions. Need starkly clear statement of problem and benefit to users.

Please respin and we'll look at this again.