>From: Natanael [mailto:[email protected]] >Sent: Dienstag, 26. November 2013 22:16 >To: [email protected] >Cc: [email protected]; grarpamp; [email protected]; [email protected]; [email protected] >Subject: RE: [cryptography] Email is unsecurable > Bote mail doesn't have to be used for it's anonymous properties, for me that is just a bonus. > For many people it is more than enough to be able to know that it is impossible for anybody > else than the intended recipient to read the message thanks to public key addressing. > Guaranteed end-to-end security if you can verify the > address. > I don't think anything that doesn't fundamentally rely on public key addressing is the (long > term) future. There will inevitably issues otherwise, including more issues of the type we > have with CA:s today.
To achieve end2end security - yes it is inevitable that endpoints will have "public key" identities, but this should not be confused with the "address"[1]. An address should have meaning to the sender and typically has a longer lifetime duration than a credential which needs changing over time and due to expiration/loss etc. > For those who want to make it more user friendly, nothing stops you from adding a transparent > "address translation layer" where servers are involved. When you want to send a message to a > person with a human readable address at a server, then the server could then reply with the > public key based address to the mail client, and the user would have the option to see what > that address is. It could even be logged by the client, with TOFU/POP style trust system that > reduces the amount of trust you have to place in the server. I think an "address translation layer" is inevitable and should be standardized. It's a possible to augment standard email with an address to say PGP-key/PK translation layer which piggybacks off DNS. 1) a service provider puts a URL link to an authoritative address to public key resolution service in a DNS record ( TXT or new MX_ADDRESS_RESOLUTION ). For example TXT="https://pk-resolver.gmail.com/resolve-address?emailaddress={}"; 2) anyone can find and query for the PK(s) to an address via the provider's service. 3) the service provider can sign the resolution responses - the service provider is the authority on which addresses exist anyway. 4) recipients can provide their providers with their PKs which match their addresses through proprietary interfaces - the how here is not so important. 5) recipients can check that their service provider publishes their correct PKs - since the recipient can check directly. If a service provider doesn't publish accurately / timely customers would change provider to ones which do - so there is no incentive here to cheat on the part of the provider. To really avoid the possibility that the service provider is performing a MITM attack, the sender would sign and send to the recipient a signed copy of the PK ( or better the authoritative response from the resolution service ). This way the recipient can check that the sender had the used the correct PK and not some forgery. > No need to trust anybody with plaintext. Too true - you cannot trust anyone with plaintext:) [1] http://pjklauser.wordpress.com/2013/03/09/deconfusing-addresses-and-identiti es/ _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
