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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> In message 
> <alpine(_dot_)DEB(_dot_)2(_dot_)00(_dot_)1310171637320(_dot_)25495(_at_)mail(_dot_)lapsedordinary(_dot_)net>
> , 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
I am in complete agreement with this. I think all references to DKIM needs to
be dropped from this draft. DKIM is not an end-to-end signature or encryption
mechanism in any case, and adapting it to be used this way diverts attention
away from what should be the focus here: Protecting the contents of messages in
transit.

I'm less sure about whether the focus should be on opportunsitic encryption
or guaranteeing a secure path. I can argue this one either way.

Beyond that there are a lot of isses with the draft, including, but not limited
to:

(1) The idea of sending a forward nondelivery notification to the recipient
    was tried in X.400. It did not work out well at all - for better or worse
    people just don't grok notifications about messages they never sent or
    received. I'm also fairly confident that our current spammy environment will
    make this problem worse, not better. As such, I think this needs to be
    dropped from the specification, and if it is retained, a specific format
    for such things needs to be specified along the lines of a DSN or MDN
    so that they can be detected and handled appropriately by an MUA.

(2) Given that this is an SMTP extension, carrying information about
    transport requirements in a header is a mistake. This should instead be
    done with a MSMD parameter on the MAIL FROM. That way the server can
    reject mail sent to recipients where it has prior knowledge that the
    necessary security requirements cannot be met. You already have serious
    issues with messages vanishing silently when the path the DSN takes
    cannot meet the necessary guarantees, so it makes sense to provide
    to avoid pointless relay operations.

    You do need a header, but one of a different sort: One that is added on
    final delivery so that POP and IMAP servers can do the right thing.
    This can have essentially the same format, but a different name is
    probably in order.

(3) I assume the purpose of the MSMD indicator in POP3 and IMAP4 is so that
    security assurances can be continued across the mail access layer. If
    so, this needs to be explained in more detail, because in that case
    the parameter really doesn't offer any sort of capability to the client.
    Rather, it is saying that certain operations the client attempts may
    fail unless the client enables the necessary level of security.

(4) You need to define a way to inform POP3 and IMAP4 clients that the
    reason they cannot access a given message is due to security requirements
    not being met. It may also be appropriate to provide an indication of
    what those security requirements are. Or not; this is a tricky one.

(5) I believe others have pointed out that the discussion of MX handling
    is inadequate. I concur.

(6) There needs to be discussion of the MSMD extension in the context of
    SUBMIT.

That will do for now.

                                Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp