--On Wednesday, October 16, 2013 10:04 +0000 Martijn Grooten
<ietf-smtp(_at_)lapsedordinary(_dot_)net> wrote:
...
5. Recommendations
I don't claim to be an expert on user interfaces or in human
understanding of tehnical protocols, but do you really think
that an average user can
make an informed decision on whether to use an option that
requires secure channels for email delivery, but still allows
for the email to be read at many placed along delivery route,
while generating the bounce in case one of the channels can't
be adequately secured?
This continues to be my biggest concern about proposals of this
type. By the time a plan of this nature gets translated and
interpreted to and by users, it will appear to be a promise of
"secure email" regardless of what the specification actually
says and what we understand to be the case. For lots of
reasons, it is often far easier for attackers (or governments
engaged in surveillance activities) to compromise a delivery
server or mail store or intermediate relays than it is to
capture a message in transit.
As Martijn points out (and I trust all of us know), hop-by-hop
transit encryption (TLS or otherwise) provides absolutely no
protection against compromised servers or relays, not just
because cleartext messages can be intercepted on such servers
but because it might be possible to "steal" enough cryptographic
information from such servers to compromise the incoming and/or
outgoing links as well.
That is certainly not an argument against doing TLS or otherwise
protecting the links because there is clearly a vunerability
there. Whether it is worth going to extra trouble (and possibly
not having messages delivered that are otherwise ok) to promise
that such methods will be used is a more complex question that
is, indeed, closely related to what the users will perceive is
being promised.
john
p.s. This is a mail transport function. Layering considerations
argue strongly that the information should be entirely in the
envelope (SMTP transaction). Requiring a relay to pull
information out of the headers, as the proposal appears to do,
is just a bad idea unless it is absolutely necessary for some
reason.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp