Subject: [Sip] SIPS: why not S/MIME instead?

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Oct 2006 09:11:44 -0800

As an alternative of my previous proposal, there seems to be quite a bit of
unhappiness of the general bogosity of the last hop (UAS) exception of SIPS.
If we remove that restriction, I guess I have to ask the question if you
want integrity/confidentiality along the path where you ultimately have no
real control over the transport chosen by middle proxies -- why don't 
you just
get/learn the cert of the intended party and use S/MIME which actually give
you the security properties that you're most likely hoping for with SIPS?

It seems to me that either S/MIME directly to the UAS or to some trusted
upstream agent for the UAS would be a *lot* better than hoping that you'll
get TLS the whole path, not least  of which is that it eliminates the lying
middle proxy problem. And if you're going to insist on TLS, you need
certs in all of those things anyway, so why not just ignore the TLS aspect
and use S/MIME?

Which isn't to say that TLS is not useful, but SIPS is trying to approximate
what S/MIME gets you, so it's not clear why you shouldn't we shouldn't
be promoting it instead of the obvious hack that SIPS is.

       Mike

_______________________________________________
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: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 31 Oct 2006 10:08:50 -0500

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, October 30, 2006 12:12 PM
> 

Because UA's rarely have certificates, or ones worth trusting.  And because
to get that cert you would have had to have contacted the UAS using a
signaling protocol (ie, SIP), so you've already done it.  Even if you make
it an options request or something benign, "they'll know".  And then S/MIME
is only a body and the message headers say a lot already - even if you have
the sip headers copied+signed+encrypted in the s/mime body, they're in the
clear in the message.  So you'll want to encrypt+auth the whole sip message
not just the body.
And honestly there's probably a reason so many proxies are record-routing,
or being b2bua's.  Trying to bypass them is a Sysiphean task.

> be promoting it instead of the obvious hack that SIPS is.

Because S/MIME has been even less successful than SIPS (if that's possible).

-hadriel

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Oct 2006 07:34:46 -0800

>or being b2bua's.  Trying to bypass them is a Sysiphean task.

Note first that I'm not trying to make light of the difficulties of S/MIME
usage (which is largely the enrollment problem as you point out). But if
SIPS is really supposed to be TLS to either to the UAS or a proxy one
up from the UAS, aren't you left with the exact same enrollment problem
regardless of whether it's TLS or S/MIME? Thus it seems to me that if
all other things are equal, wouldn't you rather choose the one that at
least eliminates the MITM attack inherent with hopwise TLS? Would
it be a satisfactory state of affairs that S/MIME and/or e2e security was
impossible because of these record-routing proxies and b2bua's? I
sure hope not.

>Because S/MIME has been even less successful than SIPS (if that's possible).
Beyond the enrollment problem, the same place you get TLS API's gets you
S/MIME API's as well (openssl). So that's probably not the problem.

Note that I'm not suggesting that S/MIME needs to necessarily be UAC to
UAS. I've always thought that these things need to be though of in terms
of "trust point" to "trust point", where "trust point" is whatever gives me
comfort. A middle to middle that allows you to fly over dangerous territory
may be exactly the right thing in many cases.

       Mike

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 31 Oct 2006 12:11:24 -0500

> Sent: Tuesday, October 31, 2006 10:35 AM
> 
> regardless of whether it's TLS or S/MIME? 

Nope - with the current model, the final UAS doesn't need a cert at all -
it's TLS connection would already be up from it registering and verifying
the proxy's/registrar's cert, and the proxy/reg verifying the UAS with
digest over the TLS connection.  Ergo why some think outbound will be the
panacea, as no (final) UAx would need to have a cert.

> Thus it seems to me that if

We can't have our cake and eat it too. :)  If none of the boxes in the
middle need to be in the signaling path, then one wonders why they are
there.  Location finding alone can't require so many hops.  But the truth is
they do a lot more than finding the location of the UAS.  Some of what they
do is unpalatable to the IETF, but the market decides those things, not the
IETF.

Even the notion of e2e security's value is seen differently by some people.
You think the UA on your PC or desk-phone is more secure than the
middle-boxes.  I assure you the owners/operators of the middle-boxes feel
the exact opposite way.

-hadriel

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 31 Oct 2006 09:54:27 -0800

Michael Thomas wrote:

> Would it be a satisfactory state of affairs that S/MIME and/or e2e 
> security was impossible because of these record-routing proxies and 
> b2bua's? I sure hope not.

Please don't hope, since it's exactly as you say: e2e security is
impossible with record routing proxies and B2BUA' since no one knows if
they may be compromised or accessible to some bad employee, etc. These
intermediaries are just MITM attacks waiting to happen.

Thanks, Henry

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]] 
Sent: Tuesday, October 31, 2006 9:35 AM
To: Hadriel Kaplan
Cc: 'IETF SIP List'
Subject: Re: [Sip] SIPS: why not S/MIME instead?

Hadriel Kaplan wrote:

>>As an alternative of my previous proposal, there seems to be quite a
bit
>>of

Note first that I'm not trying to make light of the difficulties of
S/MIME
usage (which is largely the enrollment problem as you point out). But if
SIPS is really supposed to be TLS to either to the UAS or a proxy one
up from the UAS, aren't you left with the exact same enrollment problem
regardless of whether it's TLS or S/MIME? Thus it seems to me that if
all other things are equal, wouldn't you rather choose the one that at
least eliminates the MITM attack inherent with hopwise TLS? Would
it be a satisfactory state of affairs that S/MIME and/or e2e security
was
impossible because of these record-routing proxies and b2bua's? I
sure hope not.

Note that I'm not suggesting that S/MIME needs to necessarily be UAC to
UAS. I've always thought that these things need to be though of in terms
of "trust point" to "trust point", where "trust point" is whatever gives
me
comfort. A middle to middle that allows you to fly over dangerous
territory
may be exactly the right thing in many cases.

       Mike

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 31 Oct 2006 09:54:27 -0800

Thanks, Henry

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]] 
Sent: Tuesday, October 31, 2006 9:35 AM
To: Hadriel Kaplan
Cc: 'IETF SIP List'
Subject: Re: [Sip] SIPS: why not S/MIME instead?

bit

       Mike