On Thu, Apr 20, 2017 at 11:08:20AM -0400, Paul Wouters wrote: > > I want to send you an email, so I type “paul@xxxxxxxxx” in the To: field, and my MUA goes to > > https://mail-public-keys.nohats.ca/.well-known/mail-pubkeys/paul and that gets your public key. > > But any MUA can already get my key using RFC-7929 at sha256("paul")[1:28]._openpgpkey.nohats.ca > > eg: > > dig openpgpkey 0357513deb903a056e74a7e475247fc1ffe31d8be4c1d4a31f58dd47._openpgpkey.nohats.ca. > > So using another HTTP(S) server that is not the SMTP server itself does > not seem to make much sense to me? An SMTP server relaying the > OPENPGPKEY or SMIMEA or other source of pubkey could be useful, > if we think DNS transport is bigger problem than ESMTP transport. > But I think it is harder for people to contact mx.nohats.ca on port > 25 from a random ISP compared to use DNS against 8.8.8.8 on an ISP > network. This was all covered in the discussion of draft-moore-email-addrquery. (Perhaps on the UTA rather than DANE list? I don't recall) My take at the time was (and remains) that queries for the recipient's public key can be tunneled through the user's MSA, thereby avoiding the issue of inability to reach port 25 from consumer end-device IP space. That discussion unfortunately appears to have worn-out the draft author. I still think that draft is worth pursuing, if one is willing to not set the bar too high. The reason we have so little security is sometimes (often?) because we're unwilling to accept less than "perfect" security. It is not unreasonable to trust the MSA to be a trusted proxy for remote keys. After all, in that model the same MSA/MTA operator is trusted to vend your keys to others. -- Viktor.