Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)

From: "Elwell, John" <[email-masked]>
Date: Mon, 30 Oct 2006 21:14:49 +0000

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 30 October 2006 20:55
> To: Francois Audet
> Cc: Elwell, John; IETF SIP List
> Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: 
> TLS meaning)
> 
> 
> 
> Francois Audet wrote:
> > I really don't understand why people keep on bringing the 
> padlock thing
> > again in the context of sips.
> 
> The subject line was changed to protect the guilty (er - 
> innocent). :-)
> 
> Seriously, while related its not exactly the same subject, so 
> don't take 
> it personally.
> 
> > In a request-URI, sips is merely an indication that it is 
> requested that
> > all the hops (except possibly the last one) forward this 
> request over
> > TLS. 
> > RFC3261 uses a different URI scheme for that purpose as opposed to a
> > Require
> > header, but that's water under the bridge. That 
> functionality is useful.
> 
> I think you have a good handle on having a clear definition 
> of what SIPS 
> means. IMO the question is, once that is settled, is how useful and 
> important that is.
> 
> > Many of us have explained over and over why being able to 
> request that
> > a request be sent securely over TLS is useful.
> 
> Does it solve enough problems to be worth the trouble of 
> getting deployed?
[JRE] That is the tenuous link between the new thread on the lock icon and
the original thread on SIPS. I am not yet convinced that SIPS solves real
world problems. I am not convinced that SIPS is a necessary condition for
displaying the icon.

> 
> > There is no implication of padlock icons here, neigher for 
> the sender or
> > the receiver.
> > 
> > There are many aspects to security, and it's not clear to 
> me that the
> > role of IETF is to define the meaning of a padlock. Regardles, I can
> > think of the following attribute: 
> 
> It may not be necessary for the ietf to define this, or at 
> least that it 
> make the one and only definition. But it could be important 
> to establish 
> a framework within which it is clear how to make such 
> definitions, and 
> perhaps to make one definition to serve as a proof of concept and to 
> help in understanding what dependencies there are on 
> mechanisms such as 
> SIPS.
[JRE] I agree.

> 
> > - Are MIME bodies (including SDP) encrypted end-to-end using S/MIME?
> > 
> > - Are selected parts of the SIP message itself and MIME bodies
> > (including SDP) 
> >   integrity protected end-to-end using SIP Identity (as per 
> RFC 4474)?
> > 
> > - Are the whole SIP message itself and  MIME bodies (including SDP)
> > integrity 
> >   protected end-to-end using S/MIME (as per RFC 3993)?
> > 
> > - Is media encrypted end-to-end using SRTP?
> > 
> > - Is the key negotiation used for that secured end-to-end using
> > encryption (e.g., 
> >   MIKEY, SDESC with S/MIME).
> > 
> > - Is the identity of the user sending the request secured with
> > sip-identity (RFC 4474)?
> > 
> > - Are request mapped to a non-SIP network considered "secure" (e.g.,
> > PSTN, H.323, etc.)?
> > 
> > - Can we protect against B2BUA and the likes? 
> > - etc.
> 
> I think I agree with these, though it may turn out that in 
> practice all 
> aren't necessary. Getting an idea of what it means to 
> "protect against a 
> B2BUA" could be very interesting.
> 
> > In short, there are many aspects to this, including (but not limited
> > to):
> > 
> > - Authentication of users
> > 
> > - Integrity protection
> > 
> > - Encryption of signalling
> > 
> > - Encryption of media
> > 
> > - End-to-end versus hop-by-hop
> > 
> > - Hop-of to another network (e.g., PSTN, H.323, etc.) 
> > 
> > - What cyphersuites are used
> > 
> > - etc.
> > 
> > It is not clear to me at all that we (SIP WG) can specify what the
> > padlock icon should be. 
> > Different network deployment may wish to convey different 
> information to
> > end-users.
> 
> That could lead to some nasty interoperability issues when 
> considering 
> "networks" that interconnect. Maybe it is inevitable that 
> there will be 
> limited or no real security in cases like this, but I think 
> there will 
> be demand for some. (For really disconnected networks, such as for 
> military command and control, interop probably isn't an issue and a 
> special definition would be appropriate.)
> 
> > In some deployment, you may want an indication that everything is
> > encrypted/authenticated
> > end-to-end (security, media, identity, etc.) using a 
> consolidated icon.
> > In other deployment,
> > maybe hop-by-hop is the desired behavior (e.g., inside an enterprise
> > where lawful intercept 
> > may be view as secure).
> > 
> > In some other deployment, you amy want different padlock icons for
> > different security
> > properties. Or different levels of security.
> > 
> > The point is, this is NOT SIPS. It's something else. If we decide to
> > tackle it or not
> > is another issue. I personally think it is a pretty tall 
> order, and I'm
> > not sure
> > it's the mandate of IETF.  For now, I just want to ensure 
> that we don't
> > confuse
> > padlock with SIPS.
> 
> I agree it probably isn't within the current charter. And I 
> don't know 
> where it would fall in a priority list. But I think it is 
> something that 
> will eventually need to be done, and I don't see who other 
> than the ietf 
> would be appropriate to do a general framework that could support 
> interoperability over the internet.
> 
> 	Paul
> 
> > Cheers.
<snip>

_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Mon, 30 Oct 2006 16:00:14 -0600

BTW: I read both Paul and John's email, and I'm broadly in agreement.

See below for the SIPS linkage. 

> > Does it solve enough problems to be worth the trouble of getting 
> > deployed?
> [JRE] That is the tenuous link between the new thread on the 
> lock icon and the original thread on SIPS. I am not yet 
> convinced that SIPS solves real world problems. 

My response:

As per my previous email, as well as numerous ones from others, SIPS's
role is to 
indicate that a request must be forwarded over TLS by all hops (with the
unfortunate
exception of the last one). This does solve a real and immediate real
world problem
for which there is no other solution today.

If and when we define some other more enlightened mechanism (that
supports other
security mechanism than TLS, that doesn't have the last-hop hole, that
is 
truly end-to-end, etc.), then sure, we could deprecate sips, or just not
use it. But
that is some ways ahead and highly speculative at this point.

There are people today that are strugling with implementing TLS and SIPS
with 
RFC 3261. That's what we are fixing in the short term.

> I am not 
> convinced that SIPS is a necessary condition for displaying the icon.

Correct. In fact, I would say that those are totally different topics.

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 30 Oct 2006 17:57:14 -0600

> RFC 3261. That's what we are fixing in the short term.

My concern is, If SIPS (in current form with RECOMMENDED strengths etc)
gets *DEPLOYED*, then we are INVITING the nightmare of interworking
issues with more elegant solutions (Proxy-Require/Require) already on
the table. I cannot say it more loudly.