On Aug 2, 2010, at 1:25 PM, Nicolas Williams wrote:
On Mon, Aug 02, 2010 at 12:32:23PM -0400, Perry E. Metzger wrote:
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. [...]
Well, to be fair, there is much content to be accessed insecurely for
the simple reason that there may be no way to authenticate a peer.
For
much of the web this is the case.
For example, if I'm listening to music on an Internet radio station, I
could care less about authenticating the server (unless it needs to
authenticate me, in which case I'll want mutual authentication). Same
thing if I'm reading a randmon blog entry or a random news story.
By analogy to the off-line world, we authenticate business partners,
but
in asymmetric broadcast-type media, authentication is very weak and
only
of the broadcaster to the receiver. If we authenticate broadcasters
at
all, we do it by such weak methods as recognizing logos, broadcast
frequencies, etcetera.
And, indeed, there are movie cons - and many episodes of Mission:
Impossible - that turn on the ability to plant false information by
convincingly impersonating such a medium.
In other words, context matters. And the user has to understand the
context. This also means that the UI matters. I hate to demand any
expertise of the user, but it seems unavoidable. By analogy to the
off-line world, con-jobs happen, and they happen because victims are
naive, inexperienced, ill, senile, etcetera. We can no more protect
the
innocent at all times online as off, not without their help.
It's not as if identification solves all problems anyway. A
completely secure link to use when sending your money to Bernie Madoff
still leaves you with nothing.
"There should be one mode, and it should be secure" is a good idea,
but
it's not as universally applicable as one might like. *sadness*
I think it's an oversimplification. Cryptography can, in effect,
guarantee the syntax: You receive the right bytes from a source whose
identify matches some purely internal description, and no one else
could have seen those bytes. But any real-world binding - of those
bytes to semantics, of that identity to some actual actor, of "no one
else" to trust that the sender didn't send it to Wikileaks because he
doesn't actually trust you ... all of this is entirely outside the
cryptographic envelope. There's no escaping the need to understand
the semantics, not just the syntax - as valuable as the syntax is.
SMTP and IMAP, then, definitely require secure modes. So does LDAP,
even though it's used to access -mostly- public data, and so is more
like broadcast media. NNTP must not even bother with a secure mode ;)
Are you sure? How about maintaining the privacy of the groups to
which a user subscribes? (Granted, whoever you get your feed from
obviously knows - but why should anyone in a position to see the
message stream?)
Another problem you might add to the list is tunneling. Firewalls
have
led us to build every app as a web or HTTP application, and to tunnel
all the others over port 80.
Indeed. Consider the all-too-well-named SOAP, which lets arbitrary
commands and data slip right through your firewall. If you step back
a moment and look at the whole notion of using firewalls to control
port numbers, you see just what an absurd corner we've gotten
ourselves into. We have an OS that can run multiple independent
programs at different port numbers, and is actually very competent at
keeping them isolated from each other, relying at base on hardware
protection. We've replaced it with a browser which nominally allows
only one kind of connection, but then runs multiple independent
programs at different HTTP addresses - and, with no hardware
protection to help, has proved quite incompetent at keeping them
isolated from each other. This is progress?
This makes the relevant context harder, if
not impossible to resolve without the user's help.
...but it opens the door to generations of improved DPI and other
technologies that try to do it for you. With limited success at the
original mission, but all kinds of interesting privacy-invading and
censorship-enabling new missions discovered along the way.
HTTP, sadly, needs an insecure mode.
Hmm. I'm not sure exactly sure how that follows.
-- Jerry
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
