Status of opportunistic encryption

[James A. Donald]

    --
> > It seems to me opportunistic encryption has moved to
> > the application layer, at least as far as Internet
> > mail is concerned.  Many MTAs use TLS automatically
> > with whatever certificates they can get.  Of course,
> > this only guards against active attacks, but it
> > seems to me that this is a reasonable threat model.

Victor Duchovni wrote:
> It only guards against *passive* eavesdropping. Active
> attacks can forge DNS MX records, inject BGP routes,
> ... Actual MITM resistant peer authentication with
> SMTP+TLS is extremely rare. I know it happens
> sometimes because I have it running for a small number
> of destinations, otherwise I would suspect that nobody
> is doing it.

Active attacks are rare, possibly nonexistent except for
Wifi.  If NSA and the other TLAs were doing active
attacks, they would be detected some of the time.  They
don't like being detected.

If anyone does an active attack, this is a one off
event.  If someone routinely and regularly does active
attacks, the attack will be detected, the point where
they are modifying messages will be detected, and will
be bypassed.

> I should also note that once one abandons the (still)
> unrealistic assumption of a secure DNS, it is not just
> SMTP + TLS that runs into trouble.
>
> For example, many Kerberos client libraries do a
> forward lookup (to alias- expand CNAMEs) and some
> perversely a reverse lookup (often the owner of the IP
> address is the worst source of the machine's name),
> and then give you a mutually authenticated channel to
> whatever principal they construct from now rather
> questionable data. This carries over to SASL GSSAPI,
> where GSSAPI abstraction makes working around this (in
> practice nobody tries even with native Kerberos) even
> harder.
>
> Consequently, also SSH with GSS KEX, is not MITM
> resistant when the attacker can tamper with DNS
> responses.

My understanding is that SSH when using GSS KEX does not
cache the keys, which strikes me as a amazingly stupid
idea, particularly when SSH key caching has been so
successful, and when the user thinks he knows his
security comes from key caching.  The experience with
PKI suggests that it is very difficult to have security
without durable cached keys.

> Ultimately, to close similar security issues in many
> other protocols, we need a secure DNS, but I am
> somewhat pessimistic about the likelihood of this
> happening soon.

Attacks on DNS are common, though less common than other
attacks, but they are by scammers, not TLA agencies,
perhaps because they are so easily detected.

All logons should move to SRP to avoid the phishing
problem, as this is the most direct and strongest
solution for phishing for shared secrets, and phishing
for shared secrets is the biggest problem we now have.

Encrypting DNS is unacceptable, because the very large
number of very short messages make public key encryption
an intolerable overhead.  A DNS message also has to fit
in a single datagram.

To accommodate these constraints, we need DNS
certificates sent in the clear, and signed with elliptic
curve public keys (which allow both signatures and
certificates to be short enough to fit in a datagram).
The client walks the  certificate chain from time to
time and it caches the certificates, to avoid
excessively loading the issuers of higher level
certificates.

But this is all theoretical at this stage, for DNS
attacks are not our biggest problem.  Once we have
deployed systems that make it difficult to snoop and
scam without attacking DNS, *then* we will see DNS come
under heavy attack, and *then* there will be motivation
to change the DNS system.

After all, we have not fixed or replaced PKI, despite
the enormous phishing attack that renders it useless and
irrelevant, so we are going to be slower still fixing
DNS.

    --digsig
         James A. Donald
     6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
     cwXK8++rEMivkYVd+uiumb8CD2CVphnQhorYYVxx
     4KsvRJfxM5XZMseazJM4sjSoGS386TnYrCiBhfQuF

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820            http://www.ativel.com
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]