On Mon, 2 Aug 2010 12:12:25 -0400 Adam Fields <cryptography23094...@aquick.org> wrote: > > Apropos the theses thread, this article contains mention of an > interesting security "feature": > > 'Although the GSM specifications say that a phone should pop up a > warning when it connects to a station that does not have encryption, > SIM cards disable that setting so that alerts are not displayed' > > That would be an example of a bad security tradeoff with the > intended result of not bugging the user about something over which > they have neither control nor recourse, but with the actual result > of opening a significant security hole. The incentives are also all > misaligned here. Presumably the right thing to do is refuse to > connect to any unencrypted towers, but assuming that there are some > legitimate ones out in the wild, the net effect is probably just > worse service for the end user. The user has no way to tell the > difference, which is of course the point of using encryption in the > first place.
The GSM situation is an example of many problems at once -- bad UI decisions, the bad decision to allow unencrypted traffic, bad crypto algorithms even when you get crypto, susceptibility to downgrade attacks, etc. Looking forward, the "there should be one mode, and it should be secure" philosophy would claim that there should be no insecure mode for a protocol. Of course, virtually all protocols we use right now had their origins in the days of the Crypto Wars (in which case, we often added too many knobs) or before (in the days when people assumed no crypto at all) and thus come in encrypted and unencrypted varieties of all sorts. For example, in the internet space, we have http, smtp, imap and other protocols in both plain and ssl flavors. (IPSec was originally intended to mitigate this by providing a common security layer for everything, but it failed, for many reasons. Nico mentioned one that isn't sufficiently appreciated, which was the lack of APIs to permit binding of IPSec connections to users.) Perry -- Perry E. Metzger pe...@piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com