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

On Sat, Oct 19, 2013 at 11:37 AM, Ned Freed 
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:

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.

There is another aspect to the MSMD not really addressed by the Levine
proposal, or at least directly.
MSMD is making a guarantee about private delivery (or not at all) in an
ecosystem where many of
the SMTP servers do not support STARTTLS.  If the Levine proposal uses
DKIM's public key form
DNS TXT, it may conflate support for DKIM at the destination with support
for the proposed domain
encrypted message format.  I would conjecture that this could be repaired
by using a new TXT entries
for the proposed protocol or a new DNS RR.  Their presence indicates
support for the Levine protocol.


I'm not talking about the Levine proposal here. I'm talking about MSMD's
own DKIM requirements, which are entirely superfluous to MSMD's purpose.

The other aspect is how should the Levine protocol handle situation where
the destination doesn't support
the protocol.  Presumably it shouldn't send, along with some notification
but that should be specified.


Again, I'm talking about MSMD's own DKIM requirements, not some future
use of DKIM to implement encryption.

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:

In the following I'm just responding for the MSMD proposal:

DKIM can be removed from the proposal without harm to main concepts.


Exactly. And it needs to be.


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

In the likely initial uses for MSMD, likely the sender and recipient

would

already have a relationship
that requires this feature e.g. corporate or consumer financial so

probably

would wouldn't treat
such notifications as spam.


Again, past experience says otherwise. You might also want to look at the
surprisingly high number of cases where a user presses the "this is spam"
button for a message from someone the user knows.

I'll also note that sending a forward nondelivery notification over a link
which by definition doesn't meet the message's security standards has to
expose metadata regarding the failed exchange in order to be useful. If
people are serious enough to want to use a mechanism such as this I doubt
they will be comfortable with that exposure.

That said it can be dropped without harm to
main proposal, and restored if that's found to be useful later.


And IMO should be.


(2) Given that this is an SMTP extension, carrying information about
    transport requirements in a header is a mistake.

It would very helpful if you could elaborate on this as I don't see this
argument fully.  In the MSMD proposal
the mail headers is a place to store the requirements through delivery

and

afterwards if its desired to protect through
derived messages (reply/forward).


The problem is inherent to the nature of SMTP itself - if you pass this
information in a header field it's not available until the message is
transferred. Suppose the message is sent to multiple recipients, one
of whom the MTA knows can't be delivered to while meeting the MSMD
requirements. In this case the MTA has no choice but to send a DSN
for that recipient, which could easily go awry because of the carryover
of MSMD restrictions that apply to any generated DSN.

Also consider how this appears in a user agent. The user is better off
knowing immediately that some recipients are unreachable with the required
security guarantees.

In general the sooner you're able to reject a message, the better the
infrastructure works. This is especially the case when you're doing things
that
can fail at an intermediate hop.


Understood.

   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.

I see the benefit in passing the MSMD requirements as parameters to MAIL
FROM.   If this is
place of the the SMTP client side check, then I would point out that

there

is benefit in having
the client do the check especially if the SMTP server side is ignorant of
the MSMD protocol.


And if you're passing the information in a MAIL FROM, then also having
it in a header opens the door to silly states where the two disagree. It
really needs to be one or the other. And in this case since you require
the SMTP to transfer anyway, there's no cost to using a MAIL FROM
parameter.

At a minimum there will have to be a check from the SMTP client perspective
to see if the STMP server has the MSMD extension in the EHLO response.
 Given that then I can see how any additional requirements could be checked
by a compliant SMTP server when passed MAIL FROM.


    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

Yes that's correct.

    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.

Its more that the client can declare to the server it is compliant,
otherwise the server should not (or must not if the sca option
is set) get access to the mail message.  I can clarify this in the

proposal.

There is at present no mechanism in either POP3 or IMAP4 for the client to
declare a capability to a server. You'd need to define a command to do
that.

But I have to wonder if having the client use SSL/TLS on the connection
isn't sufficient here. Yes, this means that the client may not be compliant
and may send on part of a sensitive message without the same protections
as the message it came from.

But you're fighting a losing game here. The minute you go past providing a
transport mechanism that guarantees a certain level of security and start
talking about carrying security labels around as pieces of messages move
around, you're entering the territory of a full-on multi-level security
system.

Speaking as someone who did part of the implementation of one of these,
this is
far beyond anything we should be specifying. And even if we did manage to
get
one implemented, there is substantive evidence that even experienced
security
professionals cannot deal with the result.


The "SCA" option can be removed from the document and revisited (if needed)
at some later date.


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

This can be clarified further.


(5) I believe others have pointed out that the discussion of MX

handling

    is inadequate. I concur.

Do you the various delivery patterns as described  RFC5321 sec 3.6 and

3.7

relaying
and gateways? and working through the scenarios?


Yes.


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

of

    SUBMIT.

Can you expand this more?  I'm sorry I didn't catch this.  Submit as in
Mail Submission Agent?


Yes, that's the case I'm referring to. This definitely qualifies as
a SUBMIT extension and that needs to be discussed.

                                Ned


These details can be clarified.

-Wei

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