On Thu, Oct 17, 2013 at 6:03 PM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
-----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.
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.
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.
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.
(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. That said it can be dropped without harm to
main proposal, and
restored if that's found to be useful later.
(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).
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.
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.
(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?
(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?
thanks for the comments
-Wei
That will do for now.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp