Nicolas Williams wrote:
Yes, a challenge-response password authentication protocol, normally
subject to off-line dictionary attacks by passive and active attackers
can be strengthened by throwing in channel binding to, say, a TLS
channel, such that: a) passive attacks are not possible, b) MITMs below
TLS get nothing that can be attacked off-line, and c) server
impersonators can be detected heuristically when the attacker can't
retrieve the password in real-time (such an attack is indistinguishable
from password incorrect situations, but...).
Indeed. The main problem with TLS is lack of PKI support; in principle, this
isn't true - TLS uses X509 certs, just like any other SSL based protocol - but
in practice, everyone uses self signed certificates and nobody checks them or
even caches them to see if they change.
So - interesting idea time. what if....
1) Talk strongly authenticated *all* connections, even p2p ones, using a
GoogleMail master certificate and a Googletalk.Googlemail single-use certificate
to authenticate the GoogleMail server.
2) Google got into the CA business; namely, all GoogleMail owners suddenly found
they could send and receive S/Mime messages from their googlemail accounts,
using a certificate that "just appeared" and was signed by the GoogleMail master
cert. Given the GoogleMail user base, this could make GoogleMail a defacto CA in
days.
3) This certificate was downloaded to your GoogleTalk client on login, and NEVER
cached locally
Ok, from a Security Professional's POV this would be a horror - certificates
all generated by the CA (with no guarantees they aren't available to third
parties) but it *would* bootstrap X509 into common usage, and takeup of s/mime
certificates was always the bottleneck for getting encrypted mail to go
mainstream (PGP has the same problem, but in addition has the WoT issues and up
to recently actual obtaining of the software to contend with)
I can only hope that if this *is* in the gameplan, that the certificates be
marked "autogenerated" so that in the longer term a more conventional,
clientside-generated certificate can be used instead.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
