Subject: RE: [Sip] TLS, IPSec and consensus (bug #232)

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 30 Jan 2002 16:32:15 -0600

Another round, bartender.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, January 30, 2002 9:43 AM
> To: Peterson, Jon
> Cc: [email-masked]
> Subject: [Sip] TLS, IPSec and consensus (bug #232)
> 
> 
> 
> If you're going to gauge response to IPsec, you
> need to do the same thing for TLS. I haven't seen
> a whole lot of support for it either, and many
> have raised objections to its obesity.

Obesity in contrast with your IPSec proposal, which I believe we agreed is
starved for confidentiality, key exchange, or PKI. If you fed these into
your IPSec profile, I'm sure it would become pleasantly plump (and quite a
bit more applicable to SIP and its security problems).

TNSTAAFL. You get what you pay for with your 6K.

> 3G isn't
> planning to use it on UA's; that does not bode
> well. The fact is, looking for support for either
> is not likely to get you very far. History has
> shown that ostrich behavior here is the preferred
> solution, even though that's not acceptable.

I agree that few people who read this list, unfortunately, are inclined to
participate in this discussion. Most people want security and are content to
let the security people figure it out. That leads us to the typical "silence
= consensus" rhetoric that, equally unfortunately, disproportionately favors
the incumbent. However, there has got to be a point where we have said our
peace, and somebody needs to make a judgment about where we are.

> 
> What I see right now is that we will not have an
> interoperable standard for UA's.

Well, I mean, we can have a standard - those are just paper documents.

> This is reality
> -- small footprint UA's will take the STRONGLY
> RECOMMENDED and ignore it in the blink of an
> eye. 

Implementations may ignore that, true. We welcome them to support IPSec in
our paper document.

> The SMIME recommendation is similarly a
> non-starter. 

We have a e2e requirement, and S/MIME seems to satisfy it, if anyone wants
to use it.

> The only thing that has *any*
> possibility of being implemented uniformly is
> digest and the minimal IPsec I've been talking
> about. 

Digest as it appears in bis06 buys us a little; not much. I think your IPSec
profile probably buys us about as much Digest. In fact, if we fixed
integrity for Digest (as several proposals have suggested), wouldn't Digest
would actually provide a superset of functionality of your minimal IPSec
profile? 

> Things that require hundreds of kb of code
> are going to flop on the very devices that need
> protection the most.
> 
> 
> 	   Mike
> 
> Peterson, Jon writes:
>  > 
>  > I would like to suggest, based on the list discussion that 
> has transpired to
>  > date, that the chairs consider whether or not we have 
> rough consensus in
>  > favor of the current normative text on TLS and IPSec in 
> bis06 22.3.1.
>  > 
>  > The summary I sent out earlier today (along with Brian and 
> Mike's summaries)
>  > provides an account of the current state of the 
> discussion. I believe that
>  > the bis authors have been able to present a reasonable 
> response to Mike's
>  > strenuous objections. In any event, the issues are on the 
> table, and those
>  > who have debated these issues for months have essentially 
> said their peace.
>  > If there are any further arguments, or reflections on TLS vs. IPSec
>  > transport vs. IPSec tunnel, from other members of the SIP 
> community, let's
>  > hear them now, by all means. Most respondents have 
> indicated that they can
>  > live with the text in bis06 today.
>  > 
>  > I would also note that to date the reception of the 
> proposed minimal IPSec
>  > profile (ESP transport mode HMAC-MD5-NULL) has been 
> lukewarm, I think. Some
>  > respondents have expressed a preference for tunnel mode 
> IPSec. The IESG also
>  > seems to feel that some encryption algorithm, as well as a 
> story about
>  > keying, should be a part of an IPSec profile for SIP. 
> While some encryption
>  > algorithms has been mentioned on the list (like DES, as 
> required by RFC
>  > 2406), I haven't heard one that people sound entirely 
> comfortable with.
>  > 
>  > Ultimately, we all agree that we need to arrive at an 
> IPSec profile for SIP
>  > - I just don't believe that we need to solve this problem in bis.
>  > 
>  > Jon Peterson
>  > NeuStar, Inc. 
>  > 
>  > _______________________________________________
>  > 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
> 

_______________________________________________
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: Wed, 30 Jan 2002 16:51:25 -0800 (PST)

> bit more applicable to SIP and its security problems).

Jon, 

Let's not be disingenuous here. The point is that
you can decompose IPsec in ways you cannot
decompose TLS. Nobody is prevented from fattening
up their offering. However, if you require small
UA's to be force fed a diet that they cannot
digest, you are much more likely to get a dead UA
instead of foie gras.

 > Well, I mean, we can have a standard - those are just paper documents.

An unimplemented standard is a waste of paper.

 > We have a e2e requirement, and S/MIME seems to satisfy it, if anyone wants

Right now it's a SHOULD. As in strongly
recommended. That says that there needs to be very
good reasons why you don't do it. Right now, given
the feedback on requirements, etc, I don't think
that e2e crypto rises to even a SHOULD. Nobody
implemented PGP, and nobody's been clamoring for a
replacement. It seems to be a solution in search
of a problem.

 > would actually provide a superset of functionality of your minimal IPSec

It wouldn't have the ability to add encryption, 
key distibution, etc, in a standard way. Remember
this is a *minimum*. Fixing all of that for Digest
would be a *huge* job!

	 Mike