On Sun, Dec 29, 2013 at 5:32 PM, Watson Ladd <[email protected]> wrote:
> On Sun, Dec 29, 2013 at 5:08 PM, Phillip Hallam-Baker <[email protected]> > wrote: > > > > > > > > On Sun, Dec 29, 2013 at 2:38 PM, Watson Ladd <[email protected]> > wrote: > >> > >> One obvious solution for end-to-end email encryption is to use > >> ID-based cryptography: a new record type would be defined in the DNS > >> containing the system key for an ID-based system, and the username > >> (everything before the '@') would be the identity used. This would not > >> obscure addresses or the fact of communication right now, but would > >> prevent interception at intermediate nodes. It would be webmail > >> compatible. > >> > >> Are there any issues beyond the merely cryptographic that I need to > >> consider here? Can this be shoehorned into S/MIME, or do we need to do > >> something new? In the next few days I will try to make a > >> draft/implementation for this. > > > > > > There are several problems with identity based crypto. The main one being > > that the technology > > > > 1) Requires a trusted third party > > In this system the trusted third party is already trusted right now: > they are the recipients ISP. > That is a bigger bug than you imagine. If you are going to accept the ISP is trusted then we might as well just use STARTTLS which is a done and dusted technology. The only problem TLS does not solve is that the ISPs have to be trusted. If the objective here is to allow the sender to know that only the authorized recipients can read the message, having the receiving ISP in the look isn't helping at all. It puts them at risk of being suborned. > This system doesn't interfere with spam trapping and advertising, and > so is easy to adopt. > I'm not trying to replace PGP, just make something we can turn on by > default. PGP has not met the original goal of becoming ubiquitous so replacing PGP seems to me to be a very worthwhile goal. Replacing STARTTLS with something that has message scope but is not end to end does not seem like a good proposition. > > 2) The trusted third party has knowledge of every user's private key > > A user can opt-out by running their own receiving mail server. And how then do they get the root key for their identity based crypto published? Any answer that you give here can be used to authenticate a STARTTLS key or a site wide wildcard S/MIME key. > > 3) There is no way to revoke a private key in the case of key compromise > > This one is probably the most serious limitation. I think the best way to > fix it > is to use keys with limited temporal validity periods, say by hashing > with the year or > month/year as well. Then you wait a month and the old key is expired. > Accessing old > mail gets a bit tricky here, but clients could store local copies or > servers could hand out > the needed keys if you are logged in. Which gets us back to the need to automate the key management and if we can do that then we can use traditional public key with much less effort. I know the Identity based crypto looks like it should be really fantastically useful but I have been looking at schemes for 15 odd years and still not seen any practical application where it gives value except as a device key. Identity based crypto would be a very good way for Apple, Microsoft, Google and co to put ignition crypto into a device. Every ethernet and wifi address should come with a built in crypto key that is installed during device manufacture and never leaves the device. I would never ever want to encrypt data under an ignition key but I would be happy to use such a key to authenticate an initial bootstrap process to install the long term crypto credentials for that device to use in my network. > > > > There are of course various proposals to mitigate the last problem but > none > > that does not completely erase all the benefits of identity based crypto. > > > > If the relying party is going to check some service to get key status > they > > might was well check for a certificate. > > I was thinking sender mail client. Certificates could work, but then > we would have > to serve them up efficiently, and that's likely to be a bit of a mess, > particularly if > we don't want to reveal address books. If you could give every Gmail > user a Google > signed S/MIME certificate, and have Google distribute the list > (s/Google/mail provider of choice/) > that solves the issue, but adding 64 bytes (or maybe 128 bytes) in a > DNS extension is much > easier operationally. > > > > > > > > > -- > > Website: http://hallambaker.com/ > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
