Hi John,
On Wed, Oct 16, 2013 at 4:50 AM, John C Klensin <john+smtp(_at_)jck(_dot_)com>
wrote:
--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
I agree, and if adopted and deployed, it will require user education/and
careful consideration during deployment not to overstate what this does.
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.
Do you mean TLS downgrade, poor ciphers or stealing certs? or do you mean
employing some sort of backdoor? The former two issues are dealt with in
the proposal where TLS is specified and checked. As for detecting and
mitigating bad certs, I believe this is in discussion by the IETF. A
future TLS tier 3 could be specified as best practices for cert protection
is developed. (We think this will be certificate transparency, which is
mentioned in the proposal, but is left open as to be determined by the
community)
Agreed that this proposal does nothing for subverted MTAs. One argument
though is that likely this is not at all common, and for the vast majority
of email, not going to be an issue. Only solution here is I think you're
implying is end-to-end email encryption. I should mention that the
proposal do nothing to preclude it, and I would argue its complementary as
TLS protects metadata during delivery.
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.
I would differ here. As pointed out in the proposal's motivation, leaving
mail delivery as clear text mail makes mail delivery the weakest link for
many mail providers. It invites adversaries with lots of resources to
attack this point as other interfaces become much more hardened.
-Wei
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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp