--On Friday, September 06, 2013 06:20 -0700 Pete Resnick
<presnick(_at_)qti(_dot_)qualcomm(_dot_)com> wrote:
Actually, I disagree that this fallacy is at play here. I
think we need to separate the concept of end-to-end encryption
from authentication when it comes to UI transparency. We
design UIs now where we get in the user's face about doing
encryption if we cannot authenticate the other side and we
need to get over that. In email, we insist that you
authenticate the recipient's certificate before we allow you
to install it and to start encrypting, and prefer to send
things in the clear until that is done. That's silly and is
based on the assumption that encryption isn't worth doing
*until* we know it's going to be done completely safely. We
need to separate the trust and guarantees of safeness (which
require *later* out-of-band verification) from the whole
endeavor of getting encryption used in the first place.
Pete,
At one level, I completely agree. At another, it depends on the
threat model. If the presumed attacker is skilled and has
access to packets in transit then it is necessary to assume that
safeguards against MITM attacks are well within that attacker's
resource set. If those conditions are met, then encrypting on
the basis of a a key or certificate that can't be authenticated
is delusional protection against that threat. It may still be
good protection against more casual attacks, but we do the users
the same disservice by telling them that their transmissions are
secure under those circumstances that we do by telling them that
their data are secure when they see a little lock in their web
browsers.
Certainly "encrypt first, authenticate later" is reasonable if
one doesn't send anything sensitive until authentication has
been established, but it seems to me that would require a rather
significant redesign of how people do things, not just how
protocols work.
best,
john