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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 31 Oct 2006 10:48:01 -0500

Francois,

The problem is that the Web has set a precedent for what is expected of
a "secure" Internet service.

Using httpS means secure request; lock icon means it was accomplished.

If user sees address sips, they will expect the same.  

What will they think if no icon appears?
What will they think if an icon appears?

Both, cases indicate the inconsistency with https.  Best to start over
from square 1.

Mike

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: Monday, October 30, 2006 3:03 PM
> To: Paul Kyzivat (pkyzivat); Elwell, John
> Cc: IETF SIP List
> Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: 
> TLS meaning)
> 
> I really don't understand why people keep on bringing the 
> padlock thing again in the context of sips.
> 
> 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.
> 
> Many of us have explained over and over why being able to 
> request that a request be sent securely over TLS is useful.
> 
> 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: 
> 
> - 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.
> 
> 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.
> 
> 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.
> 
> 
> Cheers.
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:[email-masked]]
> > Sent: Monday, October 30, 2006 11:11 AM
> > To: Elwell, John
> > Cc: 'IETF SIP List'
> > Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: 
> > TLS meaning)
> > 
> > I support John here. As stupid as it might seem, I think 
> this little 
> > thing is likely to be very important. And figuring out what 
> it takes 
> > to have it is a way at getting to underlying requirements 
> for security 
> > in the protocol. Perhaps there are also other requirements for 
> > security, but at least this would provide one source.
> > 
> > So far I have heard that having a SIPS connection doesn't 
> imply that 
> > one can show this lock icon. What isn't yet clear to me is if that 
> > means that SIPS is a necessary but insufficient condition, 
> or if SIPS 
> > is in fact not even helpful for providing it. I suspect it 
> isn't even 
> > helpful.
> > If not, then what *is* driving the requirements for SIPS?
> > 
> > I think I would also extend John's proposal a bit. I think 
> there *may* 
> > need to be different levels of security, where the lock icon 
> > corresponds to one of them. But this is a slippery slope, 
> because if 
> > there are too many they become confusing to users. But too 
> few of the 
> > wrong ones may not be useful in practice.
> > 
> > For instance, it may be that there is a need for "PSTN quality" 
> > security. (I imagine that *ought* to be the same as "none", but in 
> > practice I think the PSTN level security is better than basic 
> > unsecured-sip-over-internet security, so knowing you had this when 
> > connected to the PSTN could be helpful.) But a "really 
> secure" (better 
> > than PSTN) would be a great way of motivating deployment of 
> IP-based 
> > e2e telephony services.
> > 
> > 	Paul
> > 
> > Elwell, John wrote:
> > > Some of the discussion on the long thread on "TLS meaning" 
> > has led me
> > > to seek opinions on what does indeed control the lock icon,
> > since we
> > > seem to have consensus that a successful SIPS request is
> > not grounds
> > > for showing the lock icon.
> > > 
> > > The user surely will expect media to be secured end-to-end. By 
> > > end-to-end, I mean at least as far as the domain the user 
> believes 
> > > he/she is in communication with. So there has to be some
> > cryptographic
> > > assurance that the entity with which the UA agrees keys for media 
> > > security has the credentials of the entity indicated by caller or 
> > > connected party identity (From+Identity or possibly PAI). This is 
> > > probably a sufficient condition if key agreement is carried
> > out using
> > > D-H. If the key is transported, then an additional
> > condition is that
> > > the key is end-to-end encrypted, which for SDescriptions
> > means encrypted using S/MIME.
> > > 
> > > But what about the presence of B2BUAs, SBCs, etc. that do
> > not have the
> > > credentials of the end user but nevertheless terminate
> > media security? 
> > > Here the UA could find that it does media negotiation with 
> > > service-provider.net rather than with the end user
> > ([email-masked]). 
> > > It seems the lock item should not be displayed in this
> > situation. Or
> > > maybe the user could be consulted whether he/she accepts the 
> > > certificate of the intermediary even though it fails to
> > identify the remote user.
> > > 
> > > Another situation is where a user is trying to contact
> > > [email-masked] but gets back a From/Identity indicating 
> > > [email-masked] and media is secured as far as
> > > service-provider.net. Does this constitute grounds for
> > displaying the icon?
> > > 
> > > John
> > > 
> > >> -----Original Message-----
> > >> From: Hadriel Kaplan [mailto:[email-masked]]
> > >> Sent: 29 October 2006 21:26
> > >> To: 'EKR'; 'David R Oran'
> > >> Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat'; 
> 'Francois 
> > >> Audet'; 'Dean Willis'
> > >> Subject: RE: [Sip] RE: TLS meaning
> > >>
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Eric Rescorla [mailto:[email-masked]]
> > >>> Sent: Saturday, October 28, 2006 9:34 AM
> > >>> >From a security perspective, SIPS has two important properties:
> > >>>
> > >>> 1. It says to the client "you MUST talk to me over SSL".
> > >> I hope it doesn't say that.  I thought we had to use TLS. ;)
> > >>
> > >>
> > >>> 2. It says to the proxies "I expect you to make the outgoing
> > >>>    connection with TLS".
> > >>>
> > >>> As Samir has observed, the second property can be
> > provided with some
> > >>> indicator in the SIP header. However, the first can only
> > be provided
> > >>> by putting the indicator in the reference which you hand
> > >> around (i.e.,
> > >>> the SIP URI). This isn't to say it necessarily has to be
> > a new URI
> > >>> scheme--though it did in HTTP because HTTP doesn't have 
> > >>> parameters--but it's not clear to me that moving it to 
> parameters 
> > >>> would really help.
> > >> I think the part some of us are worried about is it will
> > inherit the
> > >> perception of https: namely that the entire path from the
> > caller to
> > >> the answerer is secure.  Just because an IETF doc says
> > it's not the
> > >> same, and says it's not a lock icon, will not overcome the 
> > >> perception.
> > >> Even though an
> > >> https connection is only secure to the TLS terminator (the
> > server or
> > >> an offloader), and the back-end from there is not, the
> > assumption is
> > >> the owner of the terminator takes on the responsibility 
> from there 
> > >> (if there is any responsibility).  And the terminator
> > owner wanted to
> > >> secure it between the browser and the terminator, and they
> > got that.
> > >>
> > >> But SIP is neither HTTP nor SMTP.  The sips uri may end 
> at a pstn 
> > >> gateway, or an h323 IWF, or whatever.  It may become sip 
> later, as 
> > >> well.  The owner of the TLS terminator does not
> > necessarily equal the
> > >> owner of the final UAS, nor the owner of the answerer.  
> > How can the
> > >> owner of the terminator have any responsibility for 
> something that 
> > >> may happen somewhere else, unbeknownst to him?  How/why
> > would someone
> > >> who types in a sips uri for their request not think it's
> > like https?
> > >>
> > >> In some ways the perception problem is exacerbated by the
> > uri being
> > >> the sips scheme.  If it were a require/proxy-require instead, it 
> > >> would help alleviate that perception problem, IMO.  But
> > then you're
> > >> left with trying such a request without the foreknowledge
> > of success
> > >> probability that a business-card sips address would give you.
> > >>
> > >> -hadriel
> > >>
> > >>
> > >> _______________________________________________
> > >> 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
> > > 
> > 
> > _______________________________________________
> > 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
> 

_______________________________________________
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: Tue, 31 Oct 2006 10:33:42 -0600

> From: Michael Hammer (mhammer) [mailto:[email-masked]] 
> Sent: Tuesday, October 31, 2006 7:48 AM
> To: Audet, Francois (SC100:3055); Paul Kyzivat (pkyzivat); 
> Elwell, John
> Cc: IETF SIP List
> The problem is that the Web has set a precedent for what is 
> expected of a "secure" Internet service.
> 
> Both, cases indicate the inconsistency with https.  Best to 
> start over from square 1.

Euh, no it ain't.

We can't deprecate RFC 3261. 

There are many things that aren't that great in RFC 3261, and we are not
deprecating it.

Like it or not RFC 3261 is now commercial. It doens't matter what a
bunch of
technies like us think, we can't just pull the carpet from under it for
architecture purity's sake.

SIPS is just one of them.

Like UDP transport, forking proxies, early media, ambiguity of
offer/answer,
pre-conditions, SDP in itself, PRACK, UPDATE, Contacts, the RTCP=RTP+1
rule,
bizarre case-sensitivity rules, strict routing, etc. etc.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Oct 2006 10:33:42 -0600

Euh, no it ain't.

---

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

>We can't deprecate RFC 3261. 
This is simply not true. All that it takes to deprecate SIPS: is to make 
its semantics
the same as SIP: on the receiver. As a practical matter, there is 
nothing that the
non-deprecation camp can do about that either. Assuming that this log 
jam surrounding
SIPS eventually leads to better mechanisms, a concerned sender would 
even have
the motivation to implement them if they know that SIPS is a dead letter.

       Mike