Status of opportunistic encryption
Tyler Durden
camera_lumina at hotmail.com
Tue May 30 06:03:55 PDT 2006
Another thought.
Even if everyone else doesn't encrypt, are their opportunities to "crypto
load" some services with useless, though encrypted information? Of course,
the loading can't make the service useless or even notceably degrade, or it
won't be available in the long run.
For instance, it seems to me that for some P2P services, it might be very
useful to constantly encypt and then "share" biggish files, even if no one
can actually de-encrypt the file. If the bandwidth of such encrypted files
is reasonable (though not a degrading % of the network's bandwidth), then
that service becomes a useful channel for transmitting information that's
actually encrypted, otherwise the one PGP-encrypted file that gets sent
through Kazaa or whatever is like a red cow standing in a sea of
black-and-whites. It's arguably less secure than not encrypting (ie, they
-might- not be able to read the text, but they damn sure know that this
sender/receiver is very interesting).
Actually, this may notbe too hard to acheive through something like Kazaa.
All that would be needed is N "bots" that "share" a steady stream of
encrypted files with each other.
Of course, it's far better if they do some kind of identity-hopping somehow,
or perhaps sit behind a wall of anonymity.
But this doesn't require encouraging everyone to encrypt.
In other words, if you've got a needle you want to hide it's far better to
plop some bigass haystack on it.
-TD
>From: Eugen Leitl <eugen at leitl.org>
>To: cypherpunks at jfet.org
>Subject: [Victor.Duchovni at MorganStanley.com: Re: Status of opportunistic
>encryption]
>Date: Mon, 29 May 2006 18:53:20 +0200
>
>----- Forwarded message from Victor Duchovni
><Victor.Duchovni at MorganStanley.com> -----
>
>From: Victor Duchovni <Victor.Duchovni at MorganStanley.com>
>Date: Mon, 29 May 2006 12:03:05 -0400
>To: cryptography at metzdowd.com
>Subject: Re: Status of opportunistic encryption
>Reply-To: cryptography at metzdowd.com
>User-Agent: Mutt/1.4.1i
>
>On Mon, May 29, 2006 at 07:21:29AM +0200, Florian Weimer wrote:
>
> > * Sandy Harris:
> >
> > > Recent news stories seem to me to make it obvious that anyone with
>privacy
> > > concerns (i.e. more-or-less everyone) should be encrypting as much of
>their
> > > communication as possible. Implementing opportunistic encryption is
>the
> > > best way I know of to do that for the Internet.
> > >
> > > I'm somewhat out of touch, though, so I do not know to what extent
>people
> > > are using it now. That is my question here.
> >
> > 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.
>
>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.
>
> http://www.postfix.org/TLS_README.html#client_tls_harden
>
>Once the new 2.3 TLS code is folded into the production Postfix 2.3
>snapshots (at which point the new documentation will be published), see
>
> http://www.postfix.org/TLS_README.html#client_tls_levels
> http://www.postfix.org/TLS_README.html#client_tls_policy
>
>Preview:
>
> It is regrettably the case, that TLS secure-channels (fully
>authenticated
> and immune to man-in-the-middle attacks) impose constraints on the
>sending
> and receiving sites that preclude ubiquitous deployment. One needs to
> manually configure this type of security for each destination domain,
> and in many cases implement non-default TLS policy table entries for
> additional domains hosted at a common secured destination. With Postfix
> 2.3, we make secure-channel configurations substantially easier to
> configure, but they will never be the norm. For the generic domain with
> which you have made no specific security arrangements, this security
> level is not a good fit.
>
> Historical note: while the documentation of these issues and many of
> the related features are new with Postfix 2.3, the issue was well
> understood before Postfix 1.0, when Lutz Jaenicke was designing
> the first unofficial Postfix TLS patch. See, his original post
> http://thread.gmane.org/gmane.ietf.apps-tls/304/focus=304 and the first
> response http://thread.gmane.org/gmane.ietf.apps-tls/304/focus=305. The
> problem is not even unique to SMTP or even TLS, similar issues exist
> for secure connections via aliases for HTTPS and Kerberos. SMTP merely
> uses indirect naming (via MX records) more frequently.
>
>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.
>
>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.
>
>--
>
> /"\ ASCII RIBBON NOTICE: If received in error,
> \ / CAMPAIGN Victor Duchovni please destroy and notify
> X AGAINST IT Security, sender. Sender does not waive
> / \ HTML MAIL Morgan Stanley confidentiality or privilege,
> and use is prohibited.
>
>---------------------------------------------------------------------
>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]
More information about the cypherpunks-legacy
mailing list