[Top] [All Lists]

Re: [ietf-smtp] DKIM encryption, was Request for discussion

2013-10-17 13:05:05
On 10/17/2013 07:18 PM, Martijn Grooten wrote:
On Thu, 17 Oct 2013, Richard Clayton wrote:
erk ... you don't generally wish to use public keys on whole messages,
the planet is getting pretty warm already -- there are practical reasons
why existing schemes involve encrypting with a stream cipher with a
randomly chosen session key and then just using the public key system
for transmitting the session key.  This also allows you to disclose just
the session key under some levels of legal duress -- keeping your main
key secret.

These are good points, but, as John said, it won't be hard to make this work. I do think it is good to note that the system doesn't provide perfect forward secrecy though (but I also think that's pretty much impossible with email).

there are already schemes for putting keys into DNS -- here's a write up
[there may be better discusssions, this was just the first substantive
discussion that my searching threw up] that covers three schemes (and
which points at RFCs where they exist)

Now I understand that there's more than just encryption to the proposal
(in particular the way that out of the box PGP doesn't hide Subject
header fields surprises many people), but staying closer to existing
proposals rather than trying to add this onto DKIM seems wiser

But doesn't DKIM also contain a scheme for putting keys into DNS? I don't see what these schemes offer that DKIM can't do, other than that they all focus on putting your personal key into DNS. Apart from the fact that DKIM already provides such a scheme and various software packages exist to extract the public key from the DNS record, by focusing on organisations rather than individuals, John's plan should scale well, for the same reason that DKIM is widely used, but PGP-signing email isn't.

Of course, it only provides organisation-to-organisation encryption, rather than end-to-end encryption. But this is already a big leap forward from the current situation, or from various TLS-or-bounce proposals I've seen.

It's also good to note that because of web gateways, for many organisations HTTPS only provides organisation-to-organisation encryption anyway.

Another advantage of using DKIM, apart from the existence of software that knows how to read keys, is that it may be easier to 'sell'. Seeing as every man and his dog seem to be working on a plan for post-PRISM email, this may be rather important.

Anyway, I think this deserves being written down.


There might be a potential 'conflict' however between a) the original idea of Wei, where the end-user can request from within his _MUA_ for a secure transport and b) the way DKIM operates, in general between boundary MTA's of sending ADMD and receiving ADMD. For example: the MUA can check for the existence of public keys in the domain of the intended recipient, but it doesn't know whether the MSA or his ADMD-boundary MTA and/or the receiving ADMD boundary MTA will support the requested level of security.

As for the trustworthiness of the receiving domain publishing its key: here we might benefit from the work of the repute workgroup: a better reputation might indicate (or might be interpreted) as more trustworthiness. However, it is far too simplistic to say 'trustworthiness=reputation'.

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>