ietf-smtp
[Top] [All Lists]

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

2013-10-19 13:56:46
On Sat, Oct 19, 2013 at 2:05 AM, John C Klensin <john+smtp(_at_)jck(_dot_)com> 
wrote:

--On Thursday, October 17, 2013 18:03 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:

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.

In addition to the X.400 experience, I would encourage anyone
who wants to go down that path to try to review and understand
the EAI discussions, especially in the experimental round, about
trying to fix up messages in transit and what could be done if
that were not feasible.  The X.400 experience was much more
fully developed and the general problems more obvious; the EAI
analysis was more specific to the characteristics of Internet
email and the strengths and limitations of the SMTP extension
model.


Thanks both for the pointers...  My first pass at looking for X.400 docs
has been sparse, just some wiki article but no discussion.  EAI has more.



In addition, even if there were no other issues with forward
notifications, if the idea behind this proposal is to encrypt
and thereby hide information in transit, the specific format to
which Ned refers would have to provide enough information to be
useful without disclosing anything that was supposed to be
hidden.


Yes forward notifications has the risk of leaking information as noted in
the proposal, and
presumed its use depends on the scenario and so had to be enabled.  Can be
removed.


 If it did disclose that information, we would be
essentially back to the problem of SASL fallback.  It is not
clear to me --especially in the context of the notification
coming as a surprise to the recipient that Ned mentions-- that
the resulting redacted notification would contain enough
information to be either useful or comprehensible.

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

Yes.  Mentioned earlier.


I see now, though I'd argue that putting a copying of the security header
to SMTP envelope
makes sense, and leave the message security header in place would be fine.



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

Again, some of the EAI discussions may help illuminate the
tradeoffs and issues with this.  Or perhaps not.

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

Very.  And, especially for POP3, the whole question of how to
tell a client that it cannot access a message (but that some
other client might be able to do so) is a very tricky one.
Again, a similar problem was necessarily explored as part of the
EAI work and a review by the authors of this document of that
work might be helpful.

...

The EAI work also identifies another concern that wasn't on
Ned's list.  Until EAI, there were, as far as I know, no cases
(at least no standardized ones), in which a message could be
successfully delivered to the delivery server and mail store but
a POP3 or IMAP client could find itself in a position of not
being able to retrieve that message because it lacked some
important capability.  EAI necessarily introduced one such case
-- one in which the mail store could handle non-ASCII header
information (in other than encoded word form) -- but the client
could not.  Part of what made that work more complicated was the
realization that a user might use one client, with one set of
capabilities, one day and a different one the next: assumptions
that a delivery MTA can know the intended recipient's
capabilities are quite problematic.


Agreed.  Its compounded by a limited knowledge of what those clients are,
hence the approach of having the clients self identify they are security
compliant.



There is one sense in which the problem posed by this draft is
even more complex than the EAI one.  Because EAI doesn't promise
any security above that of "bare" SMTP and IMAP/POP3, it is ok
for a POP3 or IMAP server to display a mailbox table of contents
to a client that may not be able to retrieve all of the messages
in it (even if it has to do some conversions or conventional
representations to do so).  With this new set of ideas,
displaying such a TOC in the clear might disclose information
then sender intended be kept encrypted.


This was mean to be covered be the notion of non-compliant client's being
prevented
from accessing the protected messages which in an admittedly very broad
brush
presumed things like TOC.  Another feature (assuming that it survives) that
could be clarified better.



best,
   john

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


thanks again for the detailed comments,
-Wei
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
<Prev in Thread] Current Thread [Next in Thread>