(off list)
John,
FWIW, my initial intuition/ reaction was very close to your
conclusion that, in practice, this was unlikely to accomplish
much. I've wanted to push on it a little bit because, unlike
some of the folks who have been behaving as if, if they chant
"more privacy" loudly enough, real analysis and thinking about
threat models is unnecessary, I know Jim has been around long
enough and thinks clearly enough that his draft could probably
be used to push a bit on some of those issues -- including the
ones you have identified more clearly than I have, the
circumstances in which hiding the envelope reduces the amount of
information available to an eavesdropper significantly and those
in which it doesn't, etc. I am, as predicted, finding that
discussion helpful. I hope Jim is too. Even more important,
I'm hoping that people with ideas much more naive than his are
paying attention.
A few comments below.
--On Monday, January 11, 2016 05:27 +0000 John Levine
<johnl(_at_)taugh(_dot_)com> wrote:
In the EAI case, it turns out that there is no plausible
"downgrade" path corresponding to "give up and send clear
text" in historic STARTTLS so "required extension" is the
only game in town and messages either go through or they
don't. However, the strongest critique of EAI -- IMO an
entirely valid one at least until the protocol extensions
are widely deployed -- is that it basically divides the
email world into two communities who can't talk with each
other. You risk the same type of issues here.
Only sort of. In this case, the downgrade path is obvious, you
ignore the TLS flag and send the message along.
Not quite. Jim suggests minimal replies, I'd probably want to
at least see non-return of content as a matter of principle.
Those downgrade paths, which not as obvious or trivial as just
ignoring the flag, do prevent exposing a lot of the information
the sender was presumably trying to protect.
Upon slightly more reflection, I think I see why this isn't
likely to be useful. Any MTA that understands the REQUIRETLS
flag will almost certainly do opportunistic TLS anyway, so you
haven't gained much there. In the absence of DNSSEC, you
still have the attack where a bad guy sends you a fake MX, so
you deliver 100% securely to the wrong place, so you have yet
another steel door on a cardboard box.
If you do have DNSSEC, you can use RFC 7672 TLSA to be sure
you're delivering to the right place. So what does this buy
you in practice?
Agreed, but it is a little worse. If the hypothetical bad guy
has sufficient access/control to mess with both DNS replies (to
tamper with the MS responses whether DNSSEC provides warning
about that or not) and the link that SMTP-over-TLS is
protecting, then, with only a little bit more MITM interference,
it can presumably:
(i) Let the correct MX records come back from the DNS query
(ii) Let the IP addresses associated with those MX records
come back correctly, whether as additional information or in a
separate query-response transaction. Up to this point, DNSSEC
would be happy.
(iii) Intercept the target IP address and direct the traffic
to a compromised system.
Unless I've missed something, 7672 doesn't help.
Speaking of RFC 7672, see its section 1.3 which looks to me
like it contemplates an approach like this and describes its
problems.
Yep, at last some of them.
thx.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp