[Top] [All Lists]

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

2013-10-17 17:37:38
Hash: SHA1

In message 
, Martijn Grooten <ietf-smtp(_at_)lapsedordinary(_dot_)net> writes
On Thu, 17 Oct 2013, Richard Clayton wrote:

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?

yes it does -- but this has pretty much nothing to do with DKIM in terms
of functionality  (and I had to look very carefully at the DKIM specs to
check that John Levine hadn't created a clash with DKIM selectors (he
has not) -- because that might have ended up with the same key being
used for signing and encryption, which risks a very significant security
failure; and even using different names for keys, people may decide to
be lazy, create one key and fall into this hole).

I don't 
see what these schemes offer that DKIM can't do

or vice versa  --  so I'm with Dr Occam here; concentrate on the notion
of opportunistic encryption at the message level at an early hop and the
subsequent unpacking for final delivery. That's what I haven't seen
before. Expressing this with some generic view of what sort of
encryption is involved (even if that description is later folded into
the draft) will show whether the basic idea has legs

, 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.

DKIM is widely used because of the way in which various large financial
institutions have seen it as a way of combating criminality

PGP is also widely used -- but less by organisations, more by

Anyway, I think this deserves being written down.

Yes ... but what needs to be made crystal clear is what the threat model
is perceived to be (because you can never assess a security solution
without that being fully understood); and we will avoid a lot of
iterations (as piecemeal fixes are applied) if it is reviewed by
competent security folks prior to seeing wide circulation (certainly
before adding in any of the crypto detail).

There are things that you might try and do with the crypto that may well
be safe in context, but that are generally seen as living dangerously
that it would be best to avoid.

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

Version: PGPsdk version 1.7.1

ietf-smtp mailing list

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