Update DarkMail #18
Description
DarkMail plans have changed a lot lately. Some clarifications it would be good to add:
- For key validation, DarkMail is using a modified form of DNSSEC/DANE. Essentially, provider endorses user keys. There was some mention in the talk very briefly about a forward hash in the key format, so that an auditor could detect if they have seen all the endorsed keys, or detect if provider tries to split the endorsement chain. Not perfect, since a provider might still alter the chain, but it reduces their opportunities to do so.
- For meta-data protected routing, DarkMail is using "onion headers", where sending relay doesn't know recipient and recipient relay doesn't know sender. This breaks down for single provider situations, but is a valid way to go.
- DarkMail server supports both SMTP and DMTP (their new SMTP replacement), switching between the two.
- DarkMail keys are like OpenPGP, but redesigned.