Subject: RE: [Sip] TLS section

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 28 Jan 2002 19:16:03 -0600

Well, I think this thread must be getting close to a conclusion. 

To sum up what I read below, global PKI is a myth and the IESG is
balkanized, and the standards process isn't really meaningful anyway -
"reality" must decide. Even if all of this is true, some of us believe,
irrationally perhaps, that getting this document past the IESG to RFC is
tractable, and moreover worth doing.

In any event, I do think any proposed profile for IPSec, if we end up
arriving at one, should suggest a minimum encryption algorithm. You're
probably right that one that didn't encrypt would be better than nothing,
but I think it would fall short of our requirements.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, January 28, 2002 5:00 PM
> To: Peterson, Jon
> Cc: 'Michael Thomas'; 'Rosen, Brian'; [email-masked]
> Subject: RE: [Sip] TLS section
> 
> 
> Peterson, Jon writes:
>  > Known threat models against SIP motivate a need for 
> confidentiality,
>  > regardless of what IPSec is minimally capable of 
> supporting, or what other
>  > protocols require.
> 
>    I don't actually care a lot about this. That is,
>    picking an encryption algorithm would be acceptible
>    to me too. I'm just trying to point out that a
>    minimum which didn't encrypt would be a lot better
>    than nothing, and would be acceptible as a minimum
>    must implement to me.
> 
>  > >  > Similarly, I would think there would have
>  > >  > to be some story for key exchange.
>  > > 
>  > > I don't think SIP needs to boil the ocean here. We
>  > > need a base level mechanism to make the transport
>  > > of secured SIP messages. Picking one in fact
>  > > complicates the matter by unnecessarily
>  > > constraining the design space of what is really a
>  > > system architecture issue.
>  > 
>  > The idea isn't to pick one and say you can't use any 
> alternatives - just to
>  > pick one so that SIP entities will be interoperable; then 
> system architects
>  > can use others as they like to streamline deployments, but without
>  > threatening interoperability.
> 
>    Specifying one will not get you any closer
>    to interoperability if you want meaningful
>    access control. You run into the infamous
>    "global PKI" as the next on the agenda. I
>    think steering well clear of this is by far
>    the most prudent.
> 
>  > > I think SIP mainly needs to mind its own business.
>  > > Picking winners and losers in the authentication
>  > > game is *wildly* out of charter, IMO.
>  > 
>  > I thought that we were charged by the IESG to identify the 
> tools could be
>  > used to secure our protocol - not to put out a protocol 
> and assume somebody
>  > else in the IETF, or worse various vendors/service 
> providers, must determine
>  > how to apply security to it before it can be deployed. 
> 
>    The Security Area doesn't even talk with a
>    single voice in this area. Why should SIP?
> 
>  > I understand that we need to choose something, not exclusively but
>  > minimally, that goes into our Security Considerations 
> section. Again, this
>  > is perhaps something for the IESG to clarify.
> 
>    A MUST IMPLEMENT implies that it is required
>    for interoperability. As I said before, that is
>    a false illusion; you will be stopped cold by
>    the mythical global PKI. This cannot be
>    settled in the IETF except to provide the tools
>    to let reality decide.
> 
> 		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