Yes, while I agree to some extent with Paul's analysis, I think from a pragmatic point of view Spencer's analysis is more realistic.
John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Spencer Dawkins > Sent: 09 July 2008 15:18 > To: IETF SIP List > Subject: Re: [Sip] On the need for a visual identifier of > trusted identity -Fwd: I-D > Action:draft-york-sip-visual-identifier-trusted-identity-00.txt > > Hi, Paul, > > This was a helpful note. > > ("analogy alert") - when I was working at a network > monitoring company, we > were asked to provide traffic counts for IPsec. Looking at > customer network > traces (for large ISPs) we saw way more people deploying ESP > ("authentication plus confidentiality") than AH > ("authentication without > confidentiality") - I'm not sure that we even implemented AH, > but I left > before that feature shipped. > > I'm thinking that if we didn't even see much uptake on > "knowing who you were > talking to without confidentiality" at the IP layer - that's > what AH gives > you - from networks operators, we're not likely to be able to > explain what's > happening at the application layer to end users with much subtlety. > > So I'd expect a single indicator ("it's all secure") to see > more uptake than > two indicators ("the signaling is/is not secure", "the media > is/is not > secure"). > > Your mileage may vary, and it's worth noting that my > information is about > three years old, so things could have changed since then... > > Thanks, > > Spencer > > > > I'm conflicted here. Its a tricky job to sort out which "security > > combinations" can be meaningfully distinguished to the end > user. They have > > to be both comprehensible and useful. And it must be > possible to convey > > them via a range of commonly used UAs. > > > > On one hand I think this is not an area that we ought to be > > standardizing - it is potentially a good area for innovation. OTOH, > > without some minimal expectations the whole thing is useless. > > > > I can see a bunch of combinations that potentially might be > in common use: > > > > 1) for single medium (e.g. audio) calls: > > a) nothing is secure > > b) identity is secure, media is not > > c) both identity and media is secure > > d) media is secure, identity is not > > 2) for multimedia calls (e.g. audio+video) > > a-d) as above > > *) combos where some media is secure and some not > > > > On top of that, we have the cases where the other end is a > gateway that we > > may trust, but which has to represent security properties > from its far > > side. > > > > And, there is the distinction between trust based on > transitive trust > > domains vs trust based on e2e encryption and certificates. > > > > Clearly this is *way* too much to present to the average > user, and nearly > > impossible to present without a sophisticated UI. So it > needs to be boiled > > down into just a few alternatives. > > > > John is proposing that it should all be condensed into > *two* alternatives: > > secure, and non-secure. In this case "secure" would be only > cases 1c or 2c > > above, and everything else would be insecure. > > > > Its my feeling that isn't going to be good enough. For one > thing, it means > > that there probably will be almost no secure commercial > deployments. It > > also means that vendors will want to "bend the truth" a bit > - perhaps by > > claiming that certain cases are handled more securely than > they really > > are. > > > > So, I'm leaning towards separating identity security from > media security, > > but I think I am willing to roll all media security together. > > For identity security, I'm thinking of possibly three cases: > > - secure (e2e or via transitive trust with some rules TBD) > > - secure to the PSTN (secure as above, to a PSTN gw) > > - insecure (all the rest) > > I would render this as some sort of annotation on the > callerid display. > > (Colors, icon, etc.) > > > > For media security, I suppose the same three cases apply. > This would need > > to be rendered independently of the callerid display. It > might be in the > > media stream itself. (Ring tone?) If in display, maybe it > would be a lock, > > rendered in different colors - but separate from the callerid. > > > > I think this is important because callerid is important to > people, and > > because there is probably a lot better chance of getting > secure callerid > > than secure media. Treating the PSTN as a special case is > clearly a hack. > > But again, its probably an important hack because people > think they know > > what they are getting with the PSTN (even if they are > wrong), and trust it > > more than our new fangled stuff. Also, for quite some time > most calls are > > likely to have one PSTN endpoint. Treating PSTN identity as totally > > insecure will distress people. > > > > Thanks, > > Paul > > > > Elwell, John wrote: > >> Dan, > >> > >>> -----Original Message----- > >>> From: Dan York [mailto:[EMAIL PROTECTED] Sent: 08 July 2008 19:53 > >>> To: Elwell, John > >>> Cc: IETF SIP List > >>> Subject: Re: [Sip] On the need for a visual identifier of trusted > >>> identity - Fwd: I-D > >>> Action:draft-york-sip-visual-identifier-trusted-identity-00.txt > >>> > >>> John, > >>> > >>> On Jul 8, 2008, at 3:13 AM, Elwell, John wrote: > >>> > >>>> Thanks for writing this, which I believe is an important > part of the > >>>> whole SIP Identity discussion going on at present. > >>> You're welcome. > >>> > >>>> Even if (as is > >>>> likely) the IETF does not standardise such a visual > indicator, the > >>>> IETF > >>>> should still give consideration to what sort of indicators > >>> are needed > >>>> and ensure that its protocols are able to supply sufficient > >>>> information > >>>> for a UA to be able to select the appropriate indicator. > >>> Agreed. > >>> > >>>> The only other comment I have is that I didn't see anything > >>> about the > >>>> impact of PSTN interworking. So there would seem to be at least 3 > >>>> elements that make up the security status of a call: > >>>> - the strength of authentication of the peer user or domain; > >>>> - the strength of encryption; > >>>> - whether the call is via PSTN. > >>> > >>> So as I read this comment, there are really two separate > issues I see > >>> here: > >>> > >>> 1. How do you symbolize the "trusted identity" of the > PSTN Caller ID > >>> transmitted by the PSTN-to-SIP gateway? Assuming we can > come up with a > >>> mechanism to arrive at end-to-end authenticated identity > between two > >>> SIP endpoints, we could get a "trusted identity" of the *PSTN > >>> gateway*, but we have no way of really knowing whether > the Caller ID of > >>> the call was spoofed out on the PSTN before it reached > the gateway. We > >>> therefore can't really trust the "identity" of the caller > provided to > >>> us by the PSTN gateway - even if we can get an > authenticated *SIP* > >>> identity of the gateway itself. Perhaps this is > represented to the end > >>> user as any other "untrusted" call would be. Perhaps > some systems could > >>> display that this is an inbound call from the PSTN? > >> [JRE] We could provide the gateway identity as a trusted > identity, but > >> it seems unhelpful not also to provide the PSTN number as > an untrusted > >> identity. Unfortunately this complicates the UI. > >> > >>> 2. Should the "visual identifier" be for more than just "trusted > >>> identity"? In the draft, I specifically was focusing on > the issue of > >>> trusted identity and NOT on the issue of the call being > encrypted. But > >>> in your comments you mention the "security status" of a > call which is > >>> really something more. In the context of identity, there > are several > >>> possibilities for a call two SIP endpoints: > >>> > >>> a. "Trusted identity" without signaling or media encryption. > >>> b. Trusted identity with signaling encryption but > without media > >>> encryption. > >> [JRE] The average user will not understand the difference between > >> signalling encryption and media encryption. I think any > indication of > >> encryption should mean that anything the user "sends" is encrypted, > >> which might include voice, video, messages, pictures, geographic > >> location, the fact that user A is making a call to user B, > etc.. I don't > >> think it is helpful to give the user separate indications > for these - a > >> secure call indication should mean everything is secure. So what I > >> really mean to say is that all these different factors > should be taken > >> into consideration before indicating that the call is secure. > >> I understand that your draft was focusing only on the strength of > >> identity authentication. However, the padlock on browsers > means that the > >> web site has been authenticated AND that data is > encrypted. The average > >> user might not be able to cope with two separate indicators on SIP > >> devices for these. > >> > >>> c. Trusted identity with both signaling and media encryption. > >>> > >>> And really there are another identical three > possibilities for a call > >>> between a SIP endpoint and PSTN gateway, for a total of > at least six > >>> possibilities. (Since you note you could also add in the > *strength* of > >>> the encryption.) > >>> > >>> We are rapidly leaving simple-icon-that-nontechnical-people-can- > >>> understand land. > >>> > >>> And probably getting into nuances (like encryption > strength) that may > >>> be of interest to the more paranoid of us (like me) but > not at all to > >>> the vast majority of people using the actual systems. > >> [JRE] To a first approximation this might be just "encrypted" or > >> "unencrypted". > >> > >>> My guess is that probably the average user *might* care about: > >>> > >>> 1. When I dial this number, am I really talking to my > bank? (Or when > >>> they called me, is it really them?) > >>> 2. Can I give them my credit card number without fear of > some hacker in > >>> ______ getting that number? > >> [JRE] Agreed. > >> > >>> Ideally, they'd get both in one icon or identifier.... > but I'm not sure > >>> that's always possible. There may be times when I want > to be sure it > >>> really is Hadriel Kaplan calling me but I don't really > care whether > >>> what we talk about is encrypted. But for many SIP > endpoints is it > >>> desirable - or even possible - to have multiple icons? > >> [JRE] I don't know the answer, but I think we are in basic > agreement. > >> > >>> It's an interesting problem. > >>> > >>> Dan > >>> > >>> -- > >>> Dan York, CISSP, Director of Emerging Communication Technology > >>> Office of the CTO Voxeo Corporation [EMAIL PROTECTED] > >>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > >>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > >>> > >>> Build voice applications based on open standards. > >>> Find out how at http://www.voxeo.com/free > >>> > >>> > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use [EMAIL PROTECTED] for questions on current sip > >> Use [EMAIL PROTECTED] for new developments on the application of sip > >> > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
