Subject: [Sip] bis-07.9 "sips:" additions (actually about "SIPS," not S/MIME).

From: Adam Roach <[email-masked]>
Date: Wed, 20 Feb 2002 16:03:36 -0500

Some comments on the new "sips" URI stuff added to the bis-07.9 draft;
line numbers, of course, come from the PS/PDF versions.

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

(line 990)
When a pre-existing route set is present, the procedures for populating the
Request-URI and Route header field detailed in Section 12.2.1.1 MUST be
followed, even though there is no dialog. If the Request-URI specifies a
SIPS URI, all the SIP URI in the route set MUST be converted to SIPS URI (by
changing the scheme to SIPS) before performing the processing of Section
12.2.1.1.

  Is this a safe transform to define this way? It's certainly *not*
  how HTTP tends to work. (Applies also to line 2010, 2700, 3705).
  It is also not consistently applied, as certain passages require
  nodes to upgrade URIs from "sip" to "sips", and certain other
  passages require the rejection of "sip" URIs without even trying
  their "sips" equivalents.

(line 1174)
If the original request had a SIPS URI in the Request-URI, the client MUST
discard any Contact header fields which do not contain SIPS URIs.

  I would propose this end in "...do not contain a method that will
  be used over an appropriately secured channel." If I send an INVITE
  with a "sips" URI as the Req-URI, I should be able to pursue an
  "https" uri if it is returned in a 380 response. (Same comment on
  lines 1424, 1599, 1719, 1879, 2559, and probably others).

  For some of the registrar-related things, I think you need to
  completely relax the restrictions, since the registrar won't
  necessarily know what types of URIs point to resources that can
  be contacted in a secure fashion. (If I send an INVITE and get a
  380 back with a mailto: URI, my client might be able to deduce that,
  since I have a PGP key for the address in the mailto: URI, popping
  up a mailer with PGP enabled would be a reasonable thing to do).

  Further, if the rule I object to above (about the validity of just
  changing "sip:" to "sips:") is actually in force, can't we just
  expect the UAC (or the registrar) to swap out the scheme and just
  expect everything to magically work (as I allude to above)?

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

In all, I see the need for a "sips" scheme, but I'm worried that it
hasn't been thought out well enough. The conversion from "sip" to
"sips" (and its inconsistent application) as well as the overly-
restrictive non-future-proof "MUST" strength rules that pervade
the draft about "sips" URIs only ever being able to map to other
"sips" URIs are worrisome, and I beleive that my forgoing objections
demonstrate that insufficient analysis has gone into their design.

If *at* *all* possible, I think we could avoid a huge, earth-shaking,
several-year-long-regret-inducing mistake by moving the "sips" stuff
into a seperate draft and allowing it to mature for longer than two
weeks before cementing it into an RFC.

If that's not feasible for reasons of parlimentary procedure and other
red-tape related BS, we should at least make sure we spend a good long
time thinking about the ramifications of automatically swapping out
"sips" for "sip" and are comforatble with them; making sure that *if*
such rules exist, they are applied in as many places possible to
aid interoperability; and ensuring that that "sips" plays well with
other schemes, so long as those schemes can be appropriately secured.

In particular, saying that 3xx responses to requests that have "sips"
URIs MUST NOT contain non-"sips" URIs seems completely unacceptable,
since it fails to acknowlege that the client might just know better
than the server what all other schemes mean. Further, saying that
clients MUST NOT act on non-"sips" URIs returned in such a fashion is
a rather embarassing oversight of the fact that the client may know
quite well how to secure communications over channels established
using non-"sips" URIs.

/a

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Feb 2002 22:47:31 -0500

Folks,

The sip editors, along with Allison, had a conference call this evening
to discuss the concerns, well stated by Adam in his note below, that
have been raised about sips. We think we have a set of changes that will
be made which should achieve a good tradeoff between perfect security,
and specification risk/flexibility.

Specific changes that we plan on making for bis-08:

1. a proxy that receives a request with a sips request-URI, and runs a
location service, SHOULD translate that to a sips URI (and similarly, a
UA SHOULD only put a sips URI in the contacts of a registration for a
sips address-of-record, the registrar will accept what it is told). In
the pre-release, this was a MUST. There will be accompanying text that
explains why you really, really do want to use a sips contact. However,
we leave the door open to configurations where there is sufficient
security through other, non TLS means. We think that having the
appropriate words that explain the motivation for this, ultimately
provide better security than a MUST without explanation (since
implementors might ignore it).

2. You can redirect a sips URI to anything you like, but a proxy SHOULD
NOT recurse on it unless its sips URI too. If its not, the proxy just
passes it upstream. This would allow the user to make a decision. This
means we can continue to redirect to mailto, http, and so on, but
preserve end-to-end path security if the user desires.

3. When a client (UA or proxy) has a pre-loaded route set, and it has a
sips URI in the request-URI, it doesn't "convert" any sip URI in the
route set to a sips URI. Rather, when it does the normal NAPTR
processing on that URI in the route header, it MUST only use the
"SIPS+D2X" services, so that the request gets sent securely. If there is
no DNS or NAPTR, it just uses TLS on port 5061. The spec will mandate
that a proxy listen for TLS on 5061, so that this will always work.

4. The issues about a UA converting the record-routes to sips will also
go away. Rather, a UA that receives a request over SIPS will need to put
a sips URI in the Contact header, presuming that the top record-route,
or contact if there is no record-route, is also a sips URI. If the top
record-route (or contact if not present) is not a sips URI, it has to
put a sip URI in there (otherwise, you may have an interop failure).
Similarly, a proxy can only record-route with a sips URI if the thing to
its left/right (in Record-route or contact) has a sips URI. This is the
same as the rules for record-routing with transport=tcp that we've had
all along. The rules have the property that if the originator uses sips,
the whole path will be secure. If sips was used in the middle (i.e.,
someone translated a sip URI to sips), you may not have security for the
entire path, either at call setup or for mid-dialog requests. 

5. Overall, we believe that the security of using sips:user@domain, as
opposed to sip:user@domain;transport=tls, is very significant. In fact,
I think its a fair statement that the old transport=tls mechanism
provided insufficient guarantees to be truly useful. As such, we
strongly feel that the sips mechanisms, with the changes above, should
remain in bis.

SPecific responses to Adam, based on this:

> line numbers, of course, come from the PS/PDF versions.

As per above, the route set would not be changed. All that would change
is the NAPTR processing - you have to use the "SIPS+D2X" records when
you resolve that sip URI in the top route header.

>   their "sips" equivalents.

I think that, with the above change, there is no longer any rejections
or conversions. Rather, rules that constrain what gets put in (sips URI
v. sip URI) and what DNS records you can use.

>   lines 1424, 1599, 1719, 1879, 2559, and probably others).

As per above, this constraint is relaxed. You can redirect to anything
you like, but a proxy cannot recurse on a non-sips URI. (at SHOULD NOT
strength). This mirrors the behavior for proxying in general.

>   up a mailer with PGP enabled would be a reasonable thing to do).

This was the essence of the long debate we had on the subject, with the
compromise above. You SHOULD register sips URIs, but you can register
other things so long as they can be secured. Basically, by registering
against a sips URI, the UA is making a commitment that the contact it is
registering is reachable with sufficient security. 

> hasn't been thought out well enough. 

I have a lot more confidence myself in it as a result of the discussions
this evening that will reflect in bis-08. Although things are moving
fast, it is not without careful consideration.

> The conversion from "sip" to

I hope the changes above will satisfy your concerns.

> weeks before cementing it into an RFC.

Well, that is unavoidable. Its really simple - we NEED a TLS mechanism
(we've had one in bis for a long time). The previous mechanism was found
to have holes (specifically, it didn't allow for a more rigorous notion
of transitive trust through multiple hops, and it didn't work well with
DNS (being subject to DNS attacks), and it didn't work well with
multiple TLS transports, like TCP and SCTP). The sips approach maintains
the TLS capabilities we always had before, but fixes those holes. Thus,
there will be a sips mechanism in bis. I think that, with the above
changes, it still allows us flexibility (including the ability to
upgrade that SHOULD to a MUST down the road), with a pretty good
security story.

> red-tape related BS, 

Its not procedure or BS. Its a simple fact that a spec cannot proceed
with broken mechanisms, or without sufficient security. Our TLS usage
did not provide sufficient security, and had enough flaws that it needed
to be fixed. 

> we should at least make sure we spend a good long

I think the changes described above meet your goals.

> quite well how to secure communications over channels established

Both of these suggestions (with the caveat that "client" does NOT
include a proxy; only the caller can decide whether to pursue a
non-secure redirection) have been reflected in the proposed changes.

One final note. One of the most valuable things I learned from executive
at my former employer is this pearl of wisdom, "Finished is a feature,
and arguably the most important one". I am certain that, even with these
changes, there are still questions and issues with the sips mechanism
(and indeed, everything else). However, we need to finish bis, and we
have customers anxiously waiting its arrival. Indeed, the ramifications
of not finishing are quite severe. Like everything else, it is a
tradeoff. I believe we are at the point where we have achieved a very
good tradeoff between just finishing it, and getting it perfect. That
tradeoff is not something the sip group has been very good at, so it is
sometimes a bit of a hard pill to swallow. Do not take that to mean that
I don't feel bis is ready; the confidence that I have that bis is very
solid is extremely high. Indeed, the increase in length of the spec is
almost entirely attributed to a very well specified, very complete
protocol. Being initimately familiar with this document at a level of
detail which is often frightening, I personally believe that

WE ARE FINISHED.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com