Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?)

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Feb 2002 14:24:53 -0500

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, February 15, 2002 11:48 AM
> To: EKR
> Cc: Michael Thomas; Peterson, Jon; 'Jari Arkko'; Juha Heinanen; Jonathan
> Rosenberg; Lawrence Conroy; Henry Sinnreich; [email-masked]
> Subject: Re: [Sip] 'sips' URI scheme (comments on proposal?)
> 
> Eric Rescorla writes:
>  > Michael Thomas <[email-masked]> writes:
>  > > You seem into falling into a false dichotomy that
>  > > if SMIME doesn't go into bis, we are now and
>  > > forever resigned to inadequate security for
>  > > SIP.
>  > I don't think it's a false dichotomy. Rather, it's a pretty
>  > accurate statement of the common pattern. To whit: WG produces
>  > a document with horrible security problems. Says, "we'll fix
>  > security later". Document passes. WG doesn't fix security.
> 
> Are you actually claiming that SIP without SMIME
> would be "a document with horrible security
> problems"? I sure hope not, because if you are I
> think you need to get a grip; the current PSTN
> does exactly this today, and the world has not
> come to an end.

The Internet is not the PSTN, of course.

My perspective is that S/MIME provides one really, really
important security function. We have a monster hole right now, 
IMHO, in that an eavesdropper can listen in on an INVITE,
and send fake BYE/re-INVITE or whatever to launch all kinds
of attacks. An e2e TLS/IPSec solution is not sufficient, since
it is too fragile - there will always be hops without security.
True e2e authentication is unachievable without PKI. The solution
is a self-signed cert approach, where effectively only the user
that send the initial INVITE can ever send subsequent signaling.
I think that this is terribly important, and without a sensible
solution for it, the SIP security story for bis is not good
enough.

Sure, we could have invented our own thing instead of S/MIME to
do this, but we would have gotten it wrong, it wouldn't be useful
for other things, as S/MIME is, and so on. S/MIME therefore seems
a good engineering choice to solve an important problem.

Notice that since it doesn't require a PKI to provide this feature,
I anticipate wider usage than S/MIME for email. For email, there
is no equivalent problem as we have in SIP, and S/MIME is not useful
without a client PKI. Thus, the application here suffers none of the
problems that have hampered it for email.

Lastly, Mike, I hope you seriously do not believe that the editors
are acting inappropriately in our efforts to move forward with the
spec. We are doing everything we can do move with speed and within the 
confines of the process. Getting consensus in this group is not trivial.

-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

_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Fri, 15 Feb 2002 12:00:41 -0800 (PST)

> The Internet is not the PSTN, of course.

   Yes, the Internet has conspicuously less
   security than the PSTN and yet it too still 
   seems to function without news at 11:00. One
   thing we've learned, however, is that a sure
   way to keep the appalling status quo is to
   aim too high. Given where SIP is likely to
   be deployed, this is not only high, but
   aimed perpendicular to the earth's surface.
 
 > important security function. We have a monster hole right now, 

   "Monster" is in the eye of the beholder.

 > of attacks. 

   Still exists with SMIME.

 > An e2e TLS/IPSec solution is not sufficient, since

   Fragile?

 > True e2e authentication is unachievable without PKI. 

   False, false, false. First of all, e2e
   authentication in the small/medium/large is clearly
   achievable without PKI. Authentication in the
   large for complex cross domain relationships is
   now and remains a fantasy. It is pure
   speculation whether PKI's will deliver. Indeed,
   the mobile IP working group has been
   floundering for well over a year precisely 
   because they improperly started from the false
   premise of global PKI's and the previous 
   solution needed to be scraped once that was
   pointed out as a bogus premise.

   And *please* don't trot out the terrible web
   example again. You're talking about large PKI's
   in *clients*.

 > The solution

   PKI != self-signed certs. If you want a leap
   of faith solution, SMIME is an impediment, not
   a help.

 > a good engineering choice to solve an important  problem.

   I happen to think that scalable/flexible proxy
   authentication is a lot more pressing problem.
   I don't think I'm alone. I've yet to hear
   anybody who is clamoring for the e2e problem.
   Yet, we get e2e SMIME with no list discussion
   either about the prioritization, or the
   solution. What gives?

 > confines of the process. Getting consensus in this group is not trivial.

   I think that this got put in at the last minute
   without any working group involvement,
   especially by the people who have expressed
   interest in the problem. I've seen no
   inclination to address any of the concerns 
   brought up, or consider alternatives. Why
   exactly am I supposed to not feel like this
   isn't being rammed down our throats?

	       Mike