Subject: [Sip] On Trial Balloon (on sips)

From: Eric Burger <[email-masked]>
Date: Sun, 05 Nov 2006 10:00:05 -0500

Sitting back for the past two weeks and getting immense enjoyment (and
insomnia relief) from the sips: discussion, here are my consolidated
thoughts and recommendation.

THOUGHTS
========

1. sips: really, really was meant to be "Require: TLS"
   (Especially given the *suggestion* that all sip connections
    be over TLS, if possible.)

2. Unsolvable problems are unsolvable
   (Does the PSTN gateway send a call directly to a phone, which
    results in the same *expectation* of security for Joe Average
    caller, or does the gateway send a call to another gateway into
    SIP-land, in which case Joe Average caller wanted their call
    to proceed with TLS?  In the latter case, there is no way to
    signal Joe's desire, nor a way to signal failure.  That problem
    is not solvable.)

3. Francois was tasked with editing a document offering a BCP on
   sips:, not tasked with fixing sips:.

4. Joe Average user *does* assign meaning to meaningless protocol
   tokens, even if he is dead wrong
   (Domain names are opaque, meaningless strings that translate
    to IP addresses that are almost as meaningless.  However,
    people really do expect cantata.com to refer to Cantata
    Technology.)

5. Just because something is broken and old does NOT mean we should
   hack around it.  I know I am being less than practical here, but
   the IETF really should do the right thing and fix mistakes.  We
   should NOT become 3GPP and say, "We had no clue 6 years ago how
   to do it, so we guessed.  We guessed wrong, and even though no
   one has implementations yet, since we wrote it down and ratified
   it, there is no way we could possibly do the right thing."

6. Experience from messaging world:  We *learned* from the disaster
   that was https and went with explicit link security requests.  In
   other words, SAY WHAT YOU MEAN.  By the way, it makes DNS easier,
   especially if the target of a sip: request and sips: request is
   always going to be the same.

7. Experience from messaging world:  If something isn't ironclad
   clear why one needs to implement security, it won't happen.  If
   one should use TLS, unless one feels one does not need to, one
   does not implement it.
   (Why spend more on hardware and software for encryption and
    compression if I don't have to?  I get way more calls/server if
    I don't use TLS.  I can then tell my customer that sips doesn't
    do anything for them anyway, because it is trying to solve an
    unsolvable problem.  Thus I get sales because I am cheaper than
    the competition.  Competition sees this and follows suit.  Any
    surprise why sips isn't one of the more implemented features?)

RECOMMENDATION
==============

BCP should simply state "sips is hopelessly broken and meaningless.  Will be
replaced by more robust mechanism in future.  Until then, if you want to
support, for example, secure SIMPLE, it might be useful to implement it."

All of the gateway discussion, rather than being important for a BCP,
actually is critical for explaining why sips is hopelessly broken.  We can
split hairs as to whether gateways are in or out for the discussion, or how
many gatewayed-to protocols can dance on the head of a pin, but that really
does NOT get us closer to the important point of letting the world know the
reality of the meaning of sips (why we would publish ANYTHING now) or to a
better solution.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: EKR <[email-masked]>
Date: Sun, 05 Nov 2006 09:04:04 -0800

>    always going to be the same.

Sorry, what is the claim from the "messaging world" that https was
a disaster? "Big fat success" would have been the word I would have
used.

-Ekr

---

From: Eric Burger <[email-masked]>
Date: Sun, 05 Nov 2006 12:08:31 -0500

Looking at it from a user¹s perspective, https is extremely successful.
Poor choice of words on my part.

The problem is confusing an application request for security services with a
transport indication of security services.  We now have a plethora of port
numbers and URI schemes to simply have an application request, "be secure,
now."  That is the disaster, not the user-visible feature.  Sorry that I was
not clear in the post.

See IMAP's or SUBMIT's approach to the problem of offering insecure and
secure services over the same protocol.

---

From: EKR <[email-masked]>
Date: Sun, 05 Nov 2006 09:27:33 -0800

> now."  That is the disaster, not the user-visible feature.  Sorry that I was

Sorry, I don't see why this is a particular problem, outside of religion
about conserving ports.

> secure services over the same protocol.

Funny, when *I* use IMAP/TLS, I use it over a separate port.

So, let's take a step back. There are three properties you'd like to be able to
have (defined for the moment over point-to-point connections):

1. The ability to have a reference that when dereferenced you are guaranteed
   to get a secure connection.
2. The ability for the server to demux secure and insecure connections.
3. The ability to provide "best-effort" or "opportunistic" security
   where the peers jointly determine that they support security.

So, https: is about (1). Separate ports is about (2). There's no reason
why you can't provide protocols where there's a separate URI scheme
but that share a port for TLS and regular protocol traffic. You just
need some way to demux SSL versus not. In the case of HTTP, the
Netscape guys decided it was easiest on a different port (note that
S-HTTP used the same port). Obviously, if you want (3) you need to
run over the same port (e.g., RFC 2817), but there's also often a
need to ensure downgrade (see 1).

-Ekr

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 5 Nov 2006 22:44:39 +0100

>    be over TLS, if possible.)

I think you mean "Proxy-Require: TLS"

"sips:" was originally meant as "SIP over TLS", in line with HTTP over TLS 
(RFC2818). The latter does not even contain the word "proxy", but its 
companion document, RFC2817, does.

RFC2817 defines 2 mechanisms related to https: that have so far not been 
translated to SIP:
1) The "CONNECT" method, to setup a tunnel via a proxy
2) The "Upgrade" header, to request upgrading a TCP connection to TLS 
(hop-by-hop)

I believe in particular (1) is what some people are implicitly asking for, 
as it reduces the role of proxies as men-in-the-middle and makes the TLS 
connection end-to-end.

(2) was an attempt to get rid of the different ports for http and https 
(apparently, "At the Washington DC IETF meeting in December 1997, the 
Applications Area Directors and the IESG reaffirmed that the practice of 
issuing parallel "secure" port numbers should be deprecated.", long before 
RFC3261...).

Perhaps these 2 mechanisms (1 more than 2), and an additional 
"Proxy-Require" mechanism to get "sips-or-die" forwarding behavior, would be 
a good supplement to the current arsenal?

Regards,
Jeroen