Hello, I'm new here, so I apologize if I'm repeating past arguments or asking old questions.
On Tue, Aug 27, 2013 at 8:52 PM, Jerry Leichter <leich...@lrw.com> wrote: > > On Aug 27, 2013, at 9:48 PM, Perry E. Metzger wrote: > >> On Tue, 27 Aug 2013 22:04:22 +0100 "Wendy M. Grossman" >> <wen...@pelicancrossing.net> wrote: >>> On 08/27/2013 18:34, ianG wrote: >>>> Why do we need the 1980s assumption of being able to send freely >>>> to everyone, anyway? >>> >>> It's clear you're not a journalist or working in any other >>> profession where you actually need to be able to communicate >>> spontaneously with strangers. >> >> Of course, as a reporter, you are probably getting email addresses of >> people to talk to via referral, and that could be used to get past the >> barrier. The problem of people spontaneously contacting a published >> address is harder. > Actually, it isn't, or shouldn't be. Email addresses were originally things > you typed into a terminal. They had to be short, memorable, and easy to > type. "Published" meant "printed on paper", which implied typing the thing > back in. > > But none of that matters much any more. This is (anecdotally) completely untrue. A great way to experience this personally is to start using a "strange" email address, like mine. You quickly realize how often you *say* or *write on paper* your email address. Because my email address is "odd", almost every time I say it, the listener asks me to spell it. I suspect if I could just say "bob at gmail" I wouldn't notice how often this occurs. Now I'm inspired to keep a log of how often I verbally spell an email address. It would be a grave mistake for us to say: "we're going to help the typical user, and oh by-the-way, we'll just assume verbally saying email addresses is not common." Because if it is, then any solution based on that assumption will not be adopted, and will therefore not help the fabled "typical user". If we went down the road of: "well verbal transmission is rare and hard, but introductions through cc headers are easy to hook into, so we'll only support some uses", then we're creating a solution where users will be easily confused as to the security properties of "an email address". > "Publication" is usually on-line, so contact addresses can be arbitrary > links. When we meet in person, we can exchange large numbers of bits between > our smartphones. Hell, even a business card can easily have a QR code on the > back. So I want to highlight something here: "usually" may be accurate, if we are counting "number of transmissions of email addresses over time". Perhaps more and more of that traffic, by volume, is through automated systems, relieving the burden of users saying, typing, or otherwise dealing with the string contents. However, I believe such "email transmissions" are not at all equal in importance. For example, if someone just verbally told me their email address, there's a great chance this is much more important than when I receive "h...@techsupport.example.com" over http by going to my broken product's website. > > Suppose, as in Bitcoin, my email address *is* my public key. If you wanted > to send me email, you'd have a routing problem - but I could even give you > hints: My address would be leich...@lrw.com:<public key>. You can try there > first, or you can look up my public key in some global dictionary. An > attacker could get your mail to me to go to them, but they can't read it - > you already know my public key, so only *I* can read it. The only attack > they can mount is a denial of service. I can have any number of public keys, > and all published routes to me may go through a mix - so I can minimize > metadata leakage. > > The assumption that "initial contact information" has to be something > human-processable creates the whole "how do I securely map contact > information to a key" problem. Flip it around and that problem vanishes. This assumption does *not* create a problem. The problem exists out in the world where billions of people use technology based on the understandings and habits they learned from past experience. The problem out in the world doesn't vanish no matter what "simplifying assumptions" we might make on this list. A counter to my position here is that maybe a solution needn't be used by everyone initially. If it's sufficiently usable and has any kind of networking effect, its use can spread over the population. I can't think of any networking effect for privacy or authentication that's readily apparent to users, and which is backwards compatible with existing use. I'd love to hear suggestions though! Yet another counter is that maybe a solution needn't be used by a given user in every case, for example by suffixing key material to addresses in some automatable situations like you suggest.. If the goal is authenticating human's to one another, this may not be very successful without massive user education (I'm reminded of http vs https indicators in browser uis). If, OTOH, the goal is "as much resistance to passive surveillance as possible", then maybe partial coverage, where a user has a hard time making distinctions, is acceptable on the whole. (Maybe not for individuals who are bitten by the confusion, however!) callme whatiwant > > -- Jerry > >> >> I don't claim to have all the answers, but experimentation will >> probably tell us a lot more than simply thinking in the abstract. >> >> -- >> Perry E. Metzger pe...@piermont.com >> _______________________________________________ >> The cryptography mailing list >> cryptography@metzdowd.com >> http://www.metzdowd.com/mailman/listinfo/cryptography > > _______________________________________________ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
