[Cryptography] Backup is completely separate
So I was thinking about Jon's claim that keys should be 'disposable'. Not sure if I buy that. But I did decide that key backup is a completely separate problem and demands a separate infrastructure. Let us imagine that I do the key-splitting and share in 5 places thing for my Comcast email. I probably need the same for my file system backups as well. And I probably want to be able to rely on the same in the future if I roll keys or whatever. So the way to deal with that problem is to have a separate key escrow protocol. Probably a JSON Web Service. The protocol results in a 'key escrow identifier' which is essentially just a retrieval index on the public key. So mine might be CBK:w9idkw992ksl3. Whenever I initialize a new public key, I give the keygen system that URI and that provides the information necessary to do a backup against my escrow setup. To check that I have the right one the system comes back and says 'Daleks are bad' which is the check phrase I chose when I initialized the system. Beneath the covers the backup scheme is simply locating a public key cert that matches the hash code I gave it, encrypting the private key under the specified public and sending the package to the email address registered in the cert. Probably want some sort of escrow agent that can be trusted to keep the encrypted bits of the private key pair and not lose them (Fort Meade would serve for that) and give them back when needed (ok, Google then). The reason I suggest a hash rather than a domain name is that this system has to work for decades and domain names are not stable enough over those periods. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Separating concerns
My target audience, like Perry's is people who simply can't cope with anything more complex than an email address. For me secure mail has to look feel and smell exactly the same as current mail. The only difference being that sometime the secure mailer will say 'I can't contact that person securely right now because…' I also agree that the devil is in the deployment. And that is why I think we need to separate concerns. We are not going to get anywhere if each and every one of us who has an idea has to implement an email client to make it work. And we certainly won't get any deployment if we have to deploy plug ins and other stuff for 50+ MUAs. My experience of SET was that the scheme failed largely because it lacked agility. The first draft of the protocol was to burdensome to use. But we could not persuade banks who had paid $6 million to a vendor to deploy SETv1 to pay the same vendor another $6 million for the changes necessary to deploy a V2. In the case of secure email there is an asymmetry. I think that deployed S/MIME has the problem of receiving and decrypting mail solved pretty well. The part that remains broken is establishing keys and sending the messages. Which is why I think a critical step is to separate out the parts of the problem which can fixed for all proposals from the parts where innovation is possible. I consider the following parts of the problem to be fixed: 1) Message formats: S/MIME There is no intrinsic advantage to PGP or S/MIME format so choose one format according to which has the larger installed base. S/MIME wins. End of story. This does not mean committing to S/MIME PKI, or not supporting Web of Trust, but it does mean using CMS/PKCS#7 for message packaging. 2) MUA crypto User Interface: None There must be no demand made of the user whatsoever. No button to press to send the message encrypted instead. The message is encrypted if the MUA can send it encrypted, end of story. The only UI that may be needed in the MUA would be to give the user feedback as to why something can't be sent. As it happens, I have been working on a protocol to provide exactly this degree of separation. The idea being that the MUA makes a (secured) remote procedure call to a trusted service that tells it: 1) Whether the email should be sent encrypted 2) The crypto parameters (key, algorithm, etc,) to use if so 3) (optional) proof that allows the MUA to validate the action of the trusted service if the assertion of the trusted service is audit able and the MUA understands how to validate the assertion. So here is how I would see it working, I have a scheme that combines elements of Certificate Transparency with a meta-notary scheme I have been working on. To implement this scheme I would write the necessary handlers for an omnibroker server to allow us to deploy the scheme and test it. If we find we need to tweak the scheme we tweak the omnibroker side of the scheme, the MUA side stays constant. If we think it is ready for prime time we can reduce the trust dependency on the broker by migrating some or all of the checking into the MUA. In practice it is likely that we would have omnibrokers that support more than one scheme and in particular provide support for legacy schemes as well. If we have six schemes and three get some sort of traction then we are likely to want to combine ideas into a seventh rather than fight a VHS vs Betamax. In my particular scheme the omnibroker is a permanent fixture as my approach is to attempt to mitigate the risks of using trusted third parties through separation of duties and multiple controls rather than eliminate them entirely. But I think that people will still find a value in using my scheme as a testbed even if they believe that the only acceptable approach is to eliminate the Trusted Third Parties entirely. In practice the cost of crypto expertise is always going to exceed the cost of crypto products. I don't know what folk charge in the bargain basement for crypto clues but I rather doubt its less than my plumber. If someone can make a buck from a PRISM Proof email scheme then they will have a motive to facilitate deployment and spread it quicker. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] IPv6 and IPSEC
(This is the last week before school goes back which is stopping me getting to the big iron and my coding platform if folk are wondering where the code is). I had a discussion with some IETF types. Should I suggest a BOF in Vancouver? Maybe this is an IRTF effort rather than IETF. One thing that we maybe should face is IPR considerations and move what is becoming a design discussion to a list with an established IPR rubric like Note Well. In the past I have had whole standards efforts collapse because Microsoft or whoever objected to the IPR being possibly contaminated by being discussed in a forum without an IPR regime (though I suspect that was a pretext rather than a reason). One question is whether we could make use of IPSEC and/or IPv6. Now I do not for an instant accept that we should make any proposal dependent on deployment of either. However IPv6 does have some very convenient characteristics for traffic analysis hardening. My view has always been that the proper approach to security is to have multiple layers so I would see IPSEC as being an addition to TLS and message layer security. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)
On Aug 28, 2013, at 11:18 AM, Dave Horsfall d...@horsfall.org wrote: On Wed, 28 Aug 2013, Perry E. Metzger wrote: Anyway, I've already started implementing my proposed solution to that part of the problem. There is still a need for a distributed database to handle the lookup load, though, and one that is not the DNS. (Delurking) This suggests the use of LDAP. I don't see that at all. In fact I think that nothing has hurt deployment of PKI more than LDAP. The problem for the email client is very simple: What is the key etc. to send email to al...@example.com I can solve that very easily with a HTTP lookup or a very short Web Service with JSON query syntax. If LDAP is involved there will be a consultant setting up the directory and building fancy DIT trees and racking up bills of $100,000+ for something that makes no difference to the actual query. Now if the certs are already in an LDAP directory then fine, lets pull data from that resource. But if they are not in LDAP already there are much easier ways to interface a database of certs to a query interface. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Separating concerns
On Aug 28, 2013, at 2:04 PM, Faré fah...@gmail.com wrote: On Wed, Aug 28, 2013 at 4:15 PM, Phill hal...@gmail.com wrote: My target audience, like Perry's is people who simply can't cope with anything more complex than an email address. For me secure mail has to look feel and smell exactly the same as current mail. The only difference being that sometime the secure mailer will say 'I can't contact that person securely right now because…' I agree with Perry and Phill that email experience should be essentially undisturbed in the normal case, though it's OK to add an additional authorization step. One thing that irks me, though, is the problem of the robust, secure terminal: if everything is encrypted, how does one survive the loss/theft/destruction of a computer or harddrive? I'm no ignoramus, yet I have, several times, lost data I cared about due to hardware failure or theft combined with improper backup. How is a total newbie to do? You have to have key backup to address that security goal. And that will necessarily mean that you increase your coercion risk. And which security goal you choose to satisfy is likely to depend on your situation. One solution would be to back up your private key and put the shares in one or more bank safes. But then you are vulnerable to a coercion attack on your bank. Which you can address by putting the shares in a tamper evident bag but only if you go to the bank regularly to audit it. One of the features of this problem is that if you make absolute security a requirement you are going to go absolutely potty trying to solve every element. Fortunately we can still do a lot of good by providing a system that prevents wholesale abuses. I am not a crypto-absolutist. I don't particularly want to be giving crypto to terrorists. When I was 18 I woke up to hear that the IRA had attempted to murder my cousin. However I don't want to be giving intercept power to Putin who murders people with poisoned teapots on the streets of London either. And I certainly don't trust the NSA and GCHQ with the wholesale intercept capability revealed by Snowden. Most newbies rely on things surviving despite their lack of explicit caution. Currently, they do it by basically trusting Google or some other company with their mail. Whichever way you do things to make them responsible for keys will lead to either (1) failure because it's technically too hard, and/or (2) automated attacks on the weak point that handles things for them. And for a company it is almost certain that 'secure against intercept by any government other than the US' is an acceptable solution. That's a lot of yak to shave to provide end-users (or even average geeks) with seemless secure email. I am currently working on a podcast history of the web to publicize my expert witness practice. Which had me looking at the reason Tim Berners Lee succeeded where Ted failed. The thing that distinguished their efforts was not the problems they solved. Ted had 120% of the Web ten years before Tim started. The difference was that Tim realized that some of the problems were very hard and could be punted on for a first draft. Then after the Web took off it built out infrastructure that made it possible for others to fill in the gaps. So Ted had search built in. Tim had a hole which was filled by others. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
On Aug 26, 2013, at 5:27 PM, The Doctor dr...@virtadpt.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/26/2013 08:46 AM, Phillip Hallam-Baker wrote: Which is why I think Ted Lemon's idea about using Facebook type friending may be necessary. Or Gchat-style contacts. I don't think we can rely on that for Key distribution. But I think it needs to be a part of the mix. What if the public key were baked into the user's public-facing profile in such a fashion that the client could pick it up automagickally but viewers just saw another link that they'd never click on anyway? I am thinking that I want to make face to face exchange of keys via an iPhone 'bump' type app possible Also I want to be able to use friend relationships as a spam filtering control. Perhaps you only want to accept encrypted email from people if you know them. My spam problem is a little larger than most. While I was doing anti-span at VeriSign I received a quarter of the mail for the company. I have been under a DoS attack on my mail for a considerable time. But in any case, at the moment we have email, I'm, voice and video all as separate apps unless we go through a proprietary scheme when they become one. The missing piece for email security is key discovery. If we are going to solve that problem for email we should do it for all the other apps as well. The market for secure email is going to be tiered. There will be folks like us who want to have full control and do a lot of the work ourselves and there will be people who want to buy in the expertise and then there will be institutions that need to outsource. As folk probably know, I work for Comodo and so I am interested in the possibility of establishing an enterprise market for secure email services. But that is only an interesting commercial prospect if there is a chance that secure email will become ubiquitous. In the near term, the critical mass for secure email has to come from another sector. People concerned about PRISM seems to be the constituency most likely to drive adoption. Even if the threat from other sources (Iran, Russia) is actually greater in my view. I have a protocol compiler. Just give it an abstract schema and out pops a server and client API library. Just need to add the code to implement the semantics. It is up on Sourceforge, will update later this week. Neat! Link, please? https://sourceforge.net/projects/jsonschema/ The code should be uploaded later this week or early next. Just got back from Europe and having some hardware issues of the expensive kind. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
