The Security Skeptic

Dan Briody wrote an article in InfoWorld in May 2000 called The Ten Commandments of cell phone etiquette. It's an interesting list to re-visit for several reasons.

Etiquette hasn't improved. Dan's first commandment is "Thou shalt not subject defenseless others to cell phone conversations".This one's a lost cause, Dan. It's nearly impossible to *not* overhear cell phone conversations if you are within earshot of another individual. Corollaries to this commandment from Dan included "Thou shalt turn thy cell phone off during public performances" and "Thou shalt not speak louder on thy cell phone than thou would on any other phone" Both are lost causes as well. There is, however, a silver lining for Americans regarding "loud". For ages, Americans have been easily distinguished from other tourists by their propensity to yell English at a non-English speaking individual, as if volume would improve comprehension. Not any more, laddie. The Ugly American is dead, long live (unfortunately) the Ugly Cell phoner. Lastly in this category, Dan offers, "Thou shalt not attempt to impress with thy cell phone." One word, Dan: iPhone.

Safety is marginally improved. Commandment 5 was "Thou shalt not dial while driving." Despite laws in various jurisdictions and technology assists from speed-dial, hands-free, and voice-dialing features on nearly any phone, including most "free when you sign up" models, it's again nearly impossible to drive without observing fools aplenty swerving as they dial. Automobile manufacturers are saying "BlueTooth is the answer". The BlueTooth chip manufacturers are saying, "Hallelulia, brother, BlueTooth is finally the answer to a question!" Whatever gains we make in driver attentiveness will be overtaken by GPS gawking and idiots who will arrange mirrors in vehicles so they can watch the rear-seat DVD while they drive.

Technology has rendered some commandments obsolete or irrelevant. "Thou shalt not grow too attached to thy cell phone"? Nearly impossible these days. Carriers use different bands and protocols, phones are locked, and phone technology evolves at a fraction of Moore's law. Commandment 4, "Thou shalt not wear more than two wireless devices on thy belt" is mostly obsolete. I can't remember the last time I saw someone with a pager or PDA *and* a cell phone. I do see folks with two cell phones but such folks are power users yet unaware of dual SIM card adapters.

I'd like to replace at least one of Dan's commandments with "Thou shall not use thy cell phone in a public restroom". Seriously, what do you have to say on a phone that can't wait until you've finished your business and washed your hands?"

Maybe I'll start a new list: 10 reasons to *not* borrow someone else's cell phone.

Archived at http://www.securityskeptic.com/arc20071101.htm#BlogID662 by Dave Piscitello  

Steve Crocker and I have co-authored a chapter on DNSSEC in an IGF publication, The Power of Ideas: Internet Governance in a Global Multi-STakeholder Environment. The book is available in its entirety in electronic (pdf) format here. The book covers a broad set of topics related to Internet governance: access, openness, diversity, critical Internet resources, emerging issues, and of course security. Our chapter discusses the DNS threat model and presents security measures introduced to mitigate these threats: Transaction Signatures (TSIG) and DNS Security Extensions (DNSSEC). We conclude the chapter with a look at the governance aspects of DNS Security.

If you study the book cover carefully, you'll notice that I am identified as a resident of Los Angeles; for the record, ICANN's offices are in Marina del Rey, California. I live on Hilton Head Island. If the book were a Wiki I'd fix this:-)

Archived at http://www.securityskeptic.com/arc20071101.htm#BlogID661 by Dave Piscitello  

A recent post to a slashdot post, DNSSEC is dead paints the following, bleak picture of DNSSEC:

• Until TLD's start signing zones, DNSSEC won't see the light of day.
• Until registrars figure out how to securely regsister and manage keys, DNSSEC is DoA
• Until zone managers start signing zones, DNSSEC won't achieve critical mass
• Without critical mass, uneven DNSSEC deployment has no value
• Without stub resolver support, DNSSEC is meaningless
• Until all the above happen, there is no business case for DNSSEC and TLD owners won't deploy it.

Colleague, friend, and SSAC chairman Steve Crocker chimed in with the following, insightful response:

I wouldn't choose quite the same language, but I think the specifics are on target. We do indeed need to get the TLDs signed, we do indeed need to have registrars accept keys from registrants -- see below for a bit more -- and we do indeed need for stub (or recursive) resolvers ask for signed responses and make use of them.

Here's a few details that suggest the picture is not so bleak.

1. A few TLDs are signed and more are coming. When the NSEC3 RFC is published, more TLDs will sign their zones.
2. We are beginning to work with registrars. In addition to providing a path for enterprises to convey their keys (or fingerprints), there will also have to be support for those registrants who do not manage their own zones. That is, for the many, many registrants who depend on the registrar to manage their zones, the registrars will also have to provide DNSSEC service. I expect to see successful worked examples in six months, give or take.
3. There is work underway to have DNSSEC implemented in the major end user systems.

Steve

One of the reasons I love working for and with Steve is that he can tease the key points out of "assertions" made by curmudgeons, acknowledge the factual elements of claims made more to posture than to inform, and build a strong counter-argument.

The Internet community is filled with impatient folks who have short memories. No communications system that antedated the Internet - Postal services, Pony Express, Telegraph, Telephone - evolved to the Internet's level of maturity and ubiquity in a little over 3 decades. All of these services experienced growing pains as they developed more secure services. But ubiquity has a price. Perhaps we should relax a moment, take a breath, and acknowledge that creating a more stable and secure name service while meeting the current needs of hundreds of millions of users isn't quite as simple as downloading a hosts file shortly after midnight from ISI was in the 1970s and 80s.

Archived at http://www.securityskeptic.com/arc20071101.htm#BlogID660 by Dave Piscitello  

Recently, Security Response Researcher Todd Woodward made a very interesting post to the Apple-Focus mailing list. Todd chimes in on the perennial debate of whether to make systems secure or easy to use, and offers that providing a combination of the two, coupled with *education* is simply good sense. With Todd's permission, I'm reproducing his post:

I think most users don't want to have to think about what they're doing and how they're doing it, which is why Mac OS X is a big plus in general terms. It's one reason why while developing security software (especially for consumers) you have to find a delicate balance between security and annoyance as well as security and functionality.

Thankfully in the business and enterprise arena that balanced is (supposedly) managed by someone else who has more education and (presumably) better sense.

And I think for Apple, when considering development plans that include security features, they have to balance between engineering and marketing as well as quality assurance. I can't comment on my experience with testing Leopard pre-release, but from past experience in other endeavors, some brilliant security features have to be left-out due to usability and marketing issues (also quality assurance) as well as to achieve that all important delivery deadline.

But still: Common sense rules. A little security education without having to buy anything new can make a big difference. Some potential things Apple could do towards this:

* If you don't want to complicate initial setup, then provide a security wizard for post-installation. In addition to educating users, you can walk them through all of the possible means and options for strengthening security.

* Make sure that there is a Security PDF included with the operating system or readily available online that discusses common sense practices as well as discusses the security features of Mac OS X.

* Appoint a chief security officer. (It's something that's been mentioned on this list before.) It would be great to have someone at the top thinking about security full-time.

Archived at http://www.securityskeptic.com/arc20071101.htm#BlogID659 by Dave Piscitello  

At Scott Pinzon's invitation, I joined Radio Free Internet to chat about fast flux networks. Fast flux is an attack method that uses evasion techniques to frustrate law enforcement and anti-phishing responders by constantly changing the hosts at which bogus web sites and the name servers fluxers use to lure you to them operate. Scott Pinzon's done a terrific job of making Radio Free Internet an informative and entertaining medium for learning security basics. Advanced topics are covered as well. The production of the podcasts and the personalities of both interviewers and guests are impressive. I'm excited with the results and hope to do more!

.

Archived at http://www.securityskeptic.com/arc20071101.htm#BlogID658 by Dave Piscitello