Subject: [Sip] Ciphersuites in SIP

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 3 Aug 2006 22:58:51 -0500

1) It was mentioned in the last meeting that  Proxies are trusted for
the other tasks.  So they should be trusted for the cipher-suite also.
And we need more stark requirement to justify it.  
 
    Proxies based on the policies/location db etc provide the routing.
Let us consider the case of misrouting. In case of REQUEST misrouting,
either other proxies will return "404 Not found" or other error codes.
In case of RESPONSE misrouting, REQUESTS will time -out. These excessive
errors will alert the IPS/IDS and Administrators can take the corrective
actions. This misrouting is happening among the trusted proxies (which
may be trusted for other domain) and SIP messages are only accessible to
trusted proxies.  Here trust breach is happening at the application
layer, and attackers cannot get anything if they are tapping on the
wires.  SIP message details are open to *Administrators* of other
proxies.
 
    Now consider the case of usage of bad ciphers.  If
misconfigured/bad/buggy etc proxy uses the less secure (e.g. 40 bit)
cipher, then details can be found by the attachers if they are tapping
on the wire. If  no of less secure hops increases then it gives
attackers more choices  to access the SIP message contents.  If
misconfigured proxy at the first hop itself uses the less secure stuff,
then attackers have a gold mine as the entire chain becomes less secure,
though it was not expected by the UAC. Spammers will get another place
to learn the URI's. 
 
    So we need a separate header. Proxies misconfigured etc with ciphers
opens the details on the wire. They should be verified at each hop. Thx
Dean for "Trust and Verify" idiom. Adjacent proxy collobaration was
mentione in the draft too.
 
2) BTW,  Eric was in agreement for extending the via for including the
cipher-suite and for the reverse channel. He mentioned that MTA's add
this too. 
 
3) For the future proofness of Secure Protocols, it will be good to
design the SIP with that in mind. Think outside of the current islands
deployments. It will be real difficult to find all the proxies updated
with the secure protocols etc to be developed in future. There may be
some providers, who might be providing the zero hour etc updates and
their may be  others who might be lacking. Providers may be charging
based on the level of security too. It does consitute in their
reputation also. So it's better to have it exposed to the users who care
about this. 

4) On one channel there will be one cipher-suite. So no of ciphers will
increase the no of TCP connections. Another reason for connect-reuse. Or
we keep on renegotiating the ciphers.
 
  Pl voice your concerns, if you think above arguments don't suffice the
need of ciphers with a separate header. 
  If we are in agreement, then I will go further for more details in the
next version.
 
Thx
Samir

 
   
_______________________________________________
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: Eric Rescorla <[email-masked]>
Date: Thu, 03 Aug 2006 21:43:29 -0700

"Samir Srivastava" <[email-masked]> writes:

> 1.  (*) text/plain          ( ) text/html           
>

I'm sorry, I don't understand this argument. What functionality
are you arguing for?

> cipher-suite and for the reverse channel. He mentioned that MTA's add

For signalling purposes only, not for control purposes.

I disagree.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 4 Aug 2006 01:21:14 -0500

Hi Eric,

1) Let me rephrase the first argument.

Misconfigured/buggy proxies for the SIP layer result in misrouting of
SIP message which will open the SIP message contents only to the
Administrators of the proxies. Attackers cannot peak into what is going
on the wire.

If a proxy is buggy for cipher-suites, then it opens up the channel for
the attackers who are tapping the contents on the wire and they can
decode the contents say if it is 40 bits. Here 
we need to be more careful.  
 
UAC may be configured for using any ciphers when they are dialing 911.
And when it is talking to bank with a/c no etc in KPML, or in IM session
with payload having a/c no, in similar scenarios, it may want to use
AES256 only. In AES256 request, a buggy or cheater proxy may provide the
service which it should not do. If that proxy doesn't provide the
service, then it will loose the revenue. It should be checked just at
the next hop. Otherwise this proxy opens up the chain further down the
line too for attackers. Without a separate header UAC will come to know
about the breach when it gets the response. By this time it is too late.

2) For the second comment, I will leave up to the User Agent clients to
decide how they want to interpret. IMHO, Control action is user driven
and we don't need to standardize.     

Thx
Samir

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: Thursday, August 03, 2006 9:43 PM
> To: Srivastava, Samir (SC100:8826)
> Cc: [email-masked]
> Subject: Re: [Sip] Ciphersuites in SIP
> 
> > In case of RESPONSE misrouting, REQUESTS will time -out. These 
> > excessive errors will alert the IPS/IDS and Administrators can take 
> > the corrective actions. This misrouting is happening among 
> the trusted 
> > proxies (which may be trusted for other domain) and SIP 
> messages are 
> > only accessible to trusted proxies.  Here trust breach is 
> happening at 
> > the application layer, and attackers cannot get anything if 
> they are 
> > tapping on the wires.  SIP message details are open to 
> > *Administrators* of other proxies.
> >
> > misconfigured proxy at the first hop itself uses the less secure 
> > stuff, then attackers have a gold mine as the entire chain becomes 
> > less secure, though it was not expected by the UAC. 
> Spammers will get 
> > another place to learn the URI's.
> >  
> >     So we need a separate header. Proxies misconfigured etc with 
> > ciphers opens the details on the wire. They should be 
> verified at each 
> > hop. Thx Dean for "Trust and Verify" idiom. Adjacent proxy 
> > collobaration was mentione in the draft too.
> 
> I'm sorry, I don't understand this argument. What 
> functionality are you arguing for?
> 
>

---

From: David R Oran <[email-masked]>
Date: Fri, 4 Aug 2006 08:43:24 -0400

> we need to be more careful.
You mean we forgot these in the requirements document:

Req 1A: Proxies MUST NOT have any bugs.
Req 1B: Proxies MUST NOT be misconfigured by administrators

Ah, that makes me feel better.

Dave.

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Aug 2006 11:09:24 -0500

> Ah, that makes me feel better.

There's the germ of an idea here that may make you feel better.

If we assume that we typically have a proxy chain -- that is, a  
sequence of multiple proxies, the likeliest failure mode is that not  
ALL of those proxies are misconfigured or buggy in exactly the same way.

So if each proxy knows what sort of behavior is expected, perhaps it  
can "rat out" a neighbor that isn't behaving correctly. This will at  
least give us a couple of places to look for bugs or  
misconfigurations -- either the complaining proxy is wrong. or the  
proxy it is complaining about is wrong.

So the "germ" here is that we might be able to inform the proxies  
about the cryptographic expectations such that when a peer deviates  
from those expectations the proxy knows to take action. Sure, this  
won't catch some "evil" proxies that alter the expectations -- just  
stupid ones -- but that's arguably better than nothing.

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Aug 2006 09:26:23 -0700

> stupid ones -- but that's arguably better than nothing.

No, I don't think it is better than nothing. It's primarily
added complexity to compensate for a case which we have no
particular reason to believe will occur.

I agree it's useful for a message recipient to know what
processing was applied to the messages, but I don't think
that automatic defection detection is particularly useful.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Aug 2006 09:26:23 -0700

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Aug 2006 09:24:40 -0700

> Administrators of the proxies. Attackers cannot peak into what is going

That's *one* way for a proxy to be buggy. Another way is to
send the message in the clear to some random location.

> we need to be more careful.  

I'm sorry, but it's silly to focus on this class of bugs. There
are a number of far more obvious SSL-type bugs that compromise
security in a far more serious way: bad random number generation
being the most obvious one.

> UAC may be configured for using any ciphers when they are dialing 911.

You do realize that TLS implementations generally automatically
negotiate strong algorithms when they're available, right? So
in order to get a weak set of ciphers in cases where there's a
fairly obvious ranking (as with 40-bit algorithms) you would
need to configure your proxy to ONLY do the weak algorithms.
That's not a sane configuration.

> about the breach when it gets the response. By this time it is too late.

Well, I don't see any reason to believe this particular class of bugs
is particularly likely, so we're back to the case of a malicious
proxy. Since such a proxy can trivially modify any signal of
what security is expected, there's no reasonable way to prevent
this.

-Ekr

_______________________________________________
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 .44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G92VT-000528-W4
	for [email-masked]; Fri, 04 Aug 2006 12:26:39 -0400
To: "Samir Srivastava" <[email-masked]>
Subject: Re: [Sip] Ciphersuites in SIP
From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Aug 2006 09:24:40 -0700
Cc: [email-masked]
Reply-To: EKR <[email-masked]>

> Administrators of the proxies. Attackers cannot peak into what is going

That's *one* way for a proxy to be buggy. Another way is to
send the message in the clear to some random location.

> we need to be more careful.  

I'm sorry, but it's silly to focus on this class of bugs. There
are a number of far more obvious SSL-type bugs that compromise
security in a far more serious way: bad random number generation
being the most obvious one.

> UAC may be configured for using any ciphers when they are dialing 911.

You do realize that TLS implementations generally automatically
negotiate strong algorithms when they're available, right? So
in order to get a weak set of ciphers in cases where there's a
fairly obvious ranking (as with 40-bit algorithms) you would
need to configure your proxy to ONLY do the weak algorithms.
That's not a sane configuration.

> about the breach when it gets the response. By this time it is too late.

Well, I don't see any reason to believe this particular class of bugs
is particularly likely, so we're back to the case of a malicious
proxy. Since such a proxy can trivially modify any signal of
what security is expected, there's no reasonable way to prevent
this.

-Ekr

sip

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 4 Aug 2006 11:38:58 -0500

> That's not a sane configuration.

... and, speaking of sane ...

I wouldn't dare characterize the current thinking in ECRIT, the working 
group that is supposed to be worrying about emergency calling, but a fair 
amount of discussion there has bounced off the point that getting "I'm 
sorry, your 911 call isn't secure enough/at all, please hang up and try 
again while your house is burning down/you're dodging gunfire" isn't sane, 
either ... so 911 may not be quite the right example here, since it may not 
be encrypted at all.

Hint - cell phone providers are supposed to complete 911 calls even if the 
cell phone isn't currently subscribed for any other service.

Hannes and Marc can talk about all this in more detail, of course.

Thanks,

Spencer

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Aug 2006 09:55:49 -0700

"Spencer Dawkins" <[email-masked]> writes:

> I wouldn't dare characterize the current thinking in ECRIT, the
> working group that is supposed to be worrying about emergency calling,
> but a fair amount of discussion there has bounced off the point that
> getting "I'm sorry, your 911 call isn't secure enough/at all, please
> hang up and try again while your house is burning down/you're dodging
> gunfire" isn't sane, either ... so 911 may not be quite the right
> example here, since it may not be encrypted at all.

Well, as usual there are a number of relevant security services here.
In particular, TLS provides a separate:

(1) Endpoint authentication and message integrity
(2) Confidentiality

Provided you want (1), if you configure your phone correctly TLS
will securely negotiate (2) or not.... Of course, if you're willing
to have your 911 call end up talking to the wrong person, then
TLS can't help you, but that has its own threats....

-Ekr

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Aug 2006 14:08:08 -0500

> That's not a sane configuration.

Operators and IT departments often do "insane configurations" for  
reasons they think are good.

Sometimes, one ends up next to a node with an insane configuration.

How should one decide whether or not a neighbor is insane and should  
be treated "carefully"?

We deal with humans on this level by having standards and by  
comparing public behavior against these standards. You can be as  
crazy as you want in the confines of your own mind as long as nobody  
notices . . .

What we have here is a way of communicating a "standard of behavior"  
that's established by the end-user

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Aug 2006 12:21:19 -0700

> that's established by the end-user

Again, do you have any evidence this is a problem in real life?
There are lots of insane and dangerous things an operator can
do. Why should we have protocol support for just this one?

-Ekr

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 Aug 2006 15:26:21 -0400

I think that there are a bunch of people who will read the specs with
selective filtering enabled.  You are supposed to first try it with full TLS
security, and if it fails, try it again without.  You aren't supposed to
just start with dropping all the security mechanisms.

Specifically, I think a carrier should have persistant TLS connections up to
its most commonly used emergency proxies (ESRPs).  It may be that in unusual
circumstances it cannot rapidly establish a connection, in which case it
must try again without TLS.

Oh, and BTW, in the U.S., the ciphersuite will be RSA-1024, SHA-1 or 2, and
AES.

Brian

> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Friday, August 04, 2006 12:39 PM
> To: [email-masked]

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 4 Aug 2006 15:51:08 -0500

Dave, I respectfully disagree here with you. 
In the real life scenarios, even the mission critical stuff have hit the
bugs, where lot of redundancy is employed. We designed the alternate
routes, form of proxy servers etc for this...
The problem here is misconfigured/cheater proxy is making the system
totally unsecure.
Consider the following case for the cheater proxy

UAC    ---->   P1 ------> P2 -------> P3 .....

Proxy P1 services to the UAC with the all known latest ciphersuites say
AES256 for the current state. But provider of Proxy P2 charges
differently to P1 for AES256. And As AES128 current mandatory
cipher-suite, it will say let us downgrade it to complete the request.
Some old may downgrade it to 3DES. If we don't have a cipher-suites
exposed to SIP, users cannot know what is done by the providers...

Thx
Samir

---

From: Dean Willis <[email-masked]>
Date: Fri, 4 Aug 2006 16:55:41 -0500

> Again, do you have any evidence this is a problem in real life?

Nope. But I have faith in human nature. People screw stuff up.

> do. Why should we have protocol support for just this one?

I'll agree that there are lots of things that need fixing.

But why should we ever design protocols that don't account for the  
fact that people screw stuff up?

This is just exactly like the "Should I keep STUNning a proxy when I  
have never received a STUN response from it?" argument.

One point of view says "I was told by configuration that this server  
supports STUN, so I'm just going to keep STUNning it until it works  
right. I don't care if that reduces my effective throughput by 90%".

Another says "Dude! That's not working. Maybe I should stop launching  
a DoS against myself."

Now, that all said, I will agree that there are probably higher- 
priority places to be applying this "self-defending" principle than  
detecting stupid proxies that use low-grade crypto when they have  
alternative -- priorities like making it the crypto actually work at  
all.

But we should keep this sort of thing in-mind at the design phase all  
the time. So understanding (and learning to avoid) the design-pattern  
that got us here would be a Very Good Thing.

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Aug 2006 15:04:00 -0700

> fact that people screw stuff up?

Because every additional layer of detection creates additional
complexity, and we well understand the problems of additional
complexity.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Aug 2006 15:04:00 -0700

-Ekr

---

From: Ben Campbell <[email-masked]>
Date: Fri, 4 Aug 2006 17:37:37 -0500

On Aug 4, 2006, at 4:55 PM, Dean Willis wrote:

> This is just exactly like the "Should I keep STUNning a proxy when  
> I have never received a STUN response from it?" argument.
>
> One point of view says "I was told by configuration that this  
> server supports STUN, so I'm just going to keep STUNning it until  
> it works right. I don't care if that reduces my effective  
> throughput by 90%".
>
> Another says "Dude! That's not working. Maybe I should stop  
> launching a DoS against myself."
>
> alternative -- priorities like making it the crypto actually work  
> at all.
>
> But we should keep this sort of thing in-mind at the design phase  
> all the time. So understanding (and learning to avoid) the design- 
> pattern that got us here would be a Very Good Thing.
>

Complexity breeds bugs. Complexity to work around bugs breeds new and  
different bugs.

(Yes, I am counting misconfiguration as a kind of bug.)

In general, I think we need a strong motivation that a _particular_  
potential bug is much more likely and/or damaging than most others  
before we start writing special protocol machinery around it.

(I actually don't have an opinion as to whether this particular issue  
meets that criteria.)

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 4 Aug 2006 21:23:26 -0400

Hi,
I hate to jump in on this conversation without knowing the full context, but
since you're evoking the "it's a real world problem" argument: what makes
you think as a request crosses a provider chain that the Via's from every
previous hop will make it the whole way through unscathed?  Via's rarely
survive a multi-provider crossing in the real world, I believe. 

And how do you prevent some proxy simply overwriting the security-level
header in the request/response so the UAC thinks everything is ok?  I wonder
what proxy could do that...

I must be missing something very basic.  Is the security-level field signed
and verified somehow by both ends?  
And you also assume 2 proxies in the middle don't collude?  It's not that
unlikely. 

-hadriel

> From: Samir Srivastava [mailto:[email-masked]]
> Sent: Friday, August 04, 2006 4:51 PM
> To: David R Oran
> Cc: [email-masked]
> Subject: RE: [Sip] Ciphersuites in SIP
> 
>

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 06 Aug 2006 12:41:35 +0200

>TLS can't help you, but that has its own threats....

I think it is a complexity trade-off. Security adds more code and
complexity, which as a matter of fact decreases realibility. I think
with 911 folks are more concerned by the reliability reduction caused 
by extra features than by reduction caused by missing security.

In our 911 implementation (like in many others') we little care about
features for 911 calls, be it security, database-based features, what-have-you.
Simplicity is paramount.

-jiri

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 06 Aug 2006 12:45:17 +0200

Samir,

I think your concerns relate generally to the transitive trust model lying
under hop-by-hop security. All in all, you can't be in control of the whole
path, make sure it is bug-free, super-secure, etc. If that concerns you,  or
your organization, I think you will be better off with e2e security protocols.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 06 Aug 2006 12:41:35 +0200

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 06 Aug 2006 12:45:17 +0200

Samir,

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 06 Aug 2006 12:52:45 +0200

>survive a multi-provider crossing in the real world, I believe. 

For this statement, I don't think there is evidence. Based on my field
experience I can only witness the opposite. Which is good -- mangling
and hiding header fields is quite cumbersome when it comes down to
actual operating a network.

>And you also assume 2 proxies in the middle don't collude?  It's not that

I tend to conclude with the same questions though :-) If folks are concerned about 
implications of transitive trust model in a chain of servers (and many are, for 
a bunch of reasons including but not limited to political ones, robustness, etc.)), 
they should be looking at e2e security protocols. 

I agree too that mid-term, not all e2e security features are implementable.
If not for other reasons, than because of NAT traversal: SDP rewriting (which
is mutualy exclusive to preserving any kind of security) is still widely
deployed practice under absence of wide adoption of ICE+STUN(w/TURN).

I think a good mix of hbh, e2e, and nop security is needed for best security.
hbh security is the only way for securing elements proxy servers must see
(such as request-uri). zRTP does a great e2e job for media. For the time
being SDP looks hopeless to me (i.e., a short-term nop candidate, and 
a long-term e2e candidate). etc.

-jiri

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 7 Aug 2006 15:40:04 -0400

> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: Sunday, August 06, 2006 6:53 AM
> 

Well, this is off-topic, but I would guess that's because of the differing
customer bases we serve.  :)
Typically you won't know it's happened.  All it takes for a multi-provider
multi-hop chain is for one of them to do it, and it's done.  Whereas
assuming the Via's are all included and left alone requires all the hops to
do so.  And devices other than SBCs do it too, but it's much more
fashionable to blame SBCs.

-hadriel

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 8 Aug 2006 00:27:23 -0500

Hi Jiri,

   My only requirement is, I should get the PSTN kind of security in
VoIP. In PSTN, I don't have to worry about the call pattern tracking etc
by anybody tapping on the wire. This can be done only under
CALEA by the duly authorized personnel when subpoena etc opened by the
legal authorities. I can talk my SSN, bank a/c etc without any fear.

   If SIP cannot provide this, then It will be bound to exist _only_ in
the *islands*. Which I (hope group also) don't like. Given Hop by Hop
nature of SIP, the proposal intended to address  the issue within the
SIP framework. 

Thx
Samir  

> Sent: Sunday, August 06, 2006 3:45 AM
> To: Srivastava, Samir (SC100:8826); David R Oran
> Cc: [email-masked]
> I think your concerns relate generally to the transitive 
> trust model lying under hop-by-hop security. All in all, you 
> can't be in control of the whole path, make sure it is 
> bug-free, super-secure, etc. If that concerns you,  or your 
> organization, I think you will be better off with e2e 
> security protocols.
> 
> -jiri
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 8 Aug 2006 00:30:45 -0500

Hi Jiri,

   in line below.

Thx
Samir

> 
> In our 911 implementation (like in many others') we little 
> care about features for 911 calls, be it security, 
> database-based features, what-have-you.
> Simplicity is paramount.
> 

 I quoted the 911 as one extreme where quickest call set up is
paramount. The other example of bank a/c was where security is
paramount. Simplicity is needed provided it feels me secure also...

> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Aug 2006 02:27:00 -0400

A couple of points about this:
a) We have lots of experience indicating that folks will use (and use 
widely) protocols that are less secure than we would like.  The 
assertion that It must be secure or "it will exist only in *islands*" 
does not match the observable history.
b) The PSTN is no where near as secure as the description below 
pretends.  There were and are many known security issues with SS7, 
and many ways that hackers could and did get at information in those systems.
c) By providing for end-to-end security over and above hop-by-hop 
security, the current definitions already allow for servers and users 
to offer and utilize significantly more secure capabilities than have 
existed heretofore.
d) Adding extra mechanisms to the protocol to try to detect very 
specific cases, with known limitations to those mechanisms, is not an 
effective approach to the sorts of problems you have indicated you 
would like to see addressed.
e) Much of your argument, if I have read and understood it properly, 
is about what proxies might choose to do if they choose to do a bad 
job offering security capabilities.  While such a choice is a 
problem, it is not a protocol definition problem.

Yours,
Joel M. Halpern

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 8 Aug 2006 02:37:48 -0500

Hi Jiri,

   in-line below.

Thx
Samir

> 
> For this statement, I don't think there is evidence. Based on 
> my field experience I can only witness the opposite. Which is 
> good -- mangling and hiding header fields is quite cumbersome 
> when it comes down to actual operating a network.
> 

If there is SBC/B2BUA in between, then it need to make sure that Ciphers
etc specified are acknowledged in other part of the network where it is
client. The normal proxy stuff works well.
I will add B2BUA stuff too in the next version.

> 
> I tend to conclude with the same questions though :-) If 
> folks are concerned about implications of transitive trust 
> model in a chain of servers (and many are, for a bunch of 
> reasons including but not limited to political ones, 
> robustness, etc.)), they should be looking at e2e security protocols. 
> 
> If not for other reasons, than because of NAT traversal: SDP 
> rewriting (which is mutualy exclusive to preserving any kind 
> of security) is still widely deployed practice under absence 
> of wide adoption of ICE+STUN(w/TURN).
> 
> hbh security is the only way for securing elements proxy 
> servers must see (such as request-uri). zRTP does a great e2e 
> job for media. For the time being SDP looks hopeless to me 
> (i.e., a short-term nop candidate, and a long-term e2e 
> candidate). etc.

I don't know how far FCC will let zRTP go in view of CALEA compliance it
enforces on providers. Even email/IM records are necessary by the law
enforcement. It is big political issue..
Also I don't foresee FAX going to end of life like Telex in near future.
SDP in e2e doesn't avoid the call pattern tracking etc given to
attackers by less secure hops. Refer my other responses to Joel's email.

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 8 Aug 2006 02:24:44 -0500

Hi Joel,

  Response in-line below. 

Thx
Samir

> widely) protocols that are less secure than we would like.  
> The assertion that It must be secure or "it will exist only 
> in *islands*" 

Here less secure stuff within the islands is guranteed by the owner of
the domain. Within the enterprises or the providers doing peering do the
policy enforcements etc to make sure it is secure. They peer with the
known IP addresses at the edge (with ACL etc) and they do the topology
hiding within their network. When they go out to untrusted zones, they
go through the Media gateways. Here it is not open internet style stuff.

> b) The PSTN is no where near as secure as the description 
> below pretends.  There were and are many known security 
> issues with SS7, and many ways that hackers could and did get 
> at information in those systems.

Agreed. But still SS7 unsecuirty is not as obvious as that of IP. I
don't intend to quote different sources etc.

> c) By providing for end-to-end security over and above 
> hop-by-hop security, the current definitions already allow 
> for servers and users to offer and utilize significantly more 
> secure capabilities than have existed heretofore.

I don't understand your argument here. Can you explain. If a less secure
hop is in between, it looses the purpose of other more secure hops.
IP/TLS etc security is dynamic too. It will be always N+1 game. For
example can you distinguish between two different TLS version/DTLS etc
in the current specifications.

> d) Adding extra mechanisms to the protocol to try to detect 
> very specific cases, with known limitations to those 
> mechanisms, is not an effective approach to the sorts of 
> problems you have indicated you would like to see addressed.
> e) Much of your argument, if I have read and understood it 
> properly, is about what proxies might choose to do if they 
> choose to do a bad job offering security capabilities.  While 
> such a choice is a problem, it is not a protocol definition problem.
> 

Choice is a problem here. But why we defined multiple IP Addresses for
reaching a domain in the protocol itself. There would have been no need
to specify SRV records etc. If the one route and one
Proxy (at one IPAddress) is always working. Protocols have been designed
to take care of availability e.g. VRRP. Proxies / Administrators do
commit mistakes. It will be very similar to current zombie scanning by
email spammers. When attackers find less secure hop, they can find lot
of stuff. Refer my earlier comment on the moving security definition in
IP itself. TLS itelf has two versions currently. When 3261 was written,
we mandated only AES128 and we have AES256 also. We need to have a
future proof stuff also apart from Trust and Verification as explained.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Aug 2006 11:21:51 -0400

If an end-point wants real security in communicating with another 
end-point, it should sign the request it sends.
(Yes, that prevents the teleco SBC from changing things.  But you can 
not have end-to-end security and allow devices in the middle to make 
arbitrary changes.)

Yours,
Joel M. Halpern

---

From: [email-masked]
Date: Tue, 8 Aug 2006 16:48:34 -0400

From: "Samir Srivastava" <[email-masked]>

   My only requirement is, I should get the PSTN kind of security in
   VoIP. In PSTN, I don't have to worry about the call pattern tracking etc
   by anybody tapping on the wire.

Generally, because people don't bother.  As far as I know, the data on
the wire is not protected particularly well.  In practice, it's
usually cheaper to tap the targeted user's access line, or to suborn a
person in the organization, than go to the trouble of physically
tapping a high-capacity PSTN line.  And people believe that the US
National Security Agency taps and analyzes essentially all
international communications.

People who use the PSTN for seriously sensitive purposes (banks,
military, diplomats) use end-to-end security.

   I can talk my SSN, bank a/c etc without any fear.

You can use SSL to communicate with your bank's server as well.

These proposals only make hop-by-hop security more robust against a
particular class of problems -- a proxy using a less-secure cipher
than the user would want, allowing an adversary to tap the line.  But
if we are worrying about trusting proxies, the biggest risk is
subornation of the proxy itself, INHO.

I think effort would better be spend in adding effective end-to-end
security than trying to remove one of the many weaknesses of the
hop-by-hop scheme.

Dale

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 09 Aug 2006 21:30:16 +0200

At 07:27 08/08/2006, Samir Srivastava wrote:
>VoIP.

I think with Internet you can do much better than that. Even today,
when I make my calls using TLS and use zRTP I feel I'm getting way
better security than with PSTN. I don't see how PSTN could outperform
this.

In terms of what I perceive as ideal, combination of hbh security for
must-be-processed-by-proxy-stuff plus e2e security for everything else
is just hard to beat.

-jiri

> In PSTN, I don't have to worry about the call pattern tracking etc

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 09 Aug 2006 21:23:47 +0200

>customer bases we serve.  :)

thats indeed very likely.

>multi-hop chain is for one of them to do it, and it's done. 

not really. The trouble is that with several SIP-mangling boxes in the path
it may be even hard to find which of the boxes caused the trouble because
they basically remove all kinds of "watermarks" based on some internal state.
In other words, this is a problem to transparency (RFC 2775 explains a lot
about that even though primarily focusing at IP level).

> Whereas

Well I dont think I'm blaming SBCs, I'm blaming boxes that mangle SIP messages.
As said, this causes loss of transparency. Which is not a fashion thing but
an architectural issue.

-jiri