The simplest way to get half-safe opportunistic encryption is the Open
Secret shared secret,
or equivalently, draft-ietf-ipsec-internet-key-00.txt's shared
secret. Everybody who wants to use it just adds it to their ipsec's list
of known shared secrets, and uses it unless something better is
The simplest way to get half-safe opportunistic encryption is the Open
Secret shared secret,
or equivalently, draft-ietf-ipsec-internet-key-00.txt's shared
secret. Everybody who wants to use it just adds it to their ipsec's list
of known shared secrets, and uses it unless something better is
On Tue, Mar 16, 2004 at 03:29:42PM +0800, Sandy Harris wrote:
So, the apparent solution for me seems to be the approach that the SPAM
blacklists used - publish information in a subspace of the forward DNS
space instead of using the authoritative in-addr.arpa area.
Worth discussing at
Hi,
Sandy Harris wrote:
Tarapia Tapioco wrote:
A possible implementation looks like this:
...
* Linux/KAME's IKE daemon racoon is patched to attempt retrieval of an
RSA key from said DNS repository and generate appropriate security
policies.
Cleaner solution, but more work probably.
Why
Eugen Leitl wrote:
No, anything requiring publishing DNS records won't fly. OE is
*opportunistic*. It doesn't care about what the true identity of the opposite
party is. Any shmuck on dynamic IP should be able to use it instantly, with
no observable performance degradation, using a simple patch.
a couple nitpicks on otherwise interesting points...
On Wed, Mar 17, 2004 at 09:02:17AM -0500, sunder wrote:
Look at how many folks use PGP - those who really know it and want it, or
those who know enough about it and have some easily automated
implementation that plugs in to their mail
On Wed, Mar 17, 2004 at 03:09:54PM +, petard wrote:
There's a well-supported extension for that: http://enigmail.mozdev.org/
Actually, plans are in the works to make S/MIME an extension as well, so
the two will soon be on equal footing.
PGP/GPG has failed to protect the bulf of email for
On Wed, 17 Mar 2004, Eugen Leitl wrote:
On Tue, Mar 16, 2004 at 03:29:42PM +0800, Sandy Harris wrote:
So, the apparent solution for me seems to be the approach that the SPAM
blacklists used - publish information in a subspace of the forward DNS
space instead of using the authoritative
Hi,
Sandy Harris wrote:
Tarapia Tapioco wrote:
A possible implementation looks like this:
...
* Linux/KAME's IKE daemon racoon is patched to attempt retrieval of an
RSA key from said DNS repository and generate appropriate security
policies.
Cleaner solution, but more work probably.
Why
On Tue, Mar 16, 2004 at 03:29:42PM +0800, Sandy Harris wrote:
So, the apparent solution for me seems to be the approach that the SPAM
blacklists used - publish information in a subspace of the forward DNS
space instead of using the authoritative in-addr.arpa area.
Worth discussing at
a couple nitpicks on otherwise interesting points...
On Wed, Mar 17, 2004 at 09:02:17AM -0500, sunder wrote:
Look at how many folks use PGP - those who really know it and want it, or
those who know enough about it and have some easily automated
implementation that plugs in to their mail
Eugen Leitl wrote:
No, anything requiring publishing DNS records won't fly. OE is
*opportunistic*. It doesn't care about what the true identity of the opposite
party is. Any shmuck on dynamic IP should be able to use it instantly, with
no observable performance degradation, using a simple patch.
On Wed, Mar 17, 2004 at 03:09:54PM +, petard wrote:
There's a well-supported extension for that: http://enigmail.mozdev.org/
Actually, plans are in the works to make S/MIME an extension as well, so
the two will soon be on equal footing.
PGP/GPG has failed to protect the bulf of email for
Hi,
Sandy Harris wrote:
Tarapia Tapioco wrote:
A possible implementation looks like this:
...
* Linux/KAME's IKE daemon racoon is patched to attempt retrieval of an
RSA key from said DNS repository and generate appropriate security
policies.
Cleaner solution, but more work probably.
Why
Tarapia Tapioco wrote:
We've recently seen FreeS/WAN die, not least due to the apparent
practical failure of Opportunistic Encryption. The largest blocking
point for deployment of OE always seemed to be the requirement for
publishing one's key in the reverse DNS space. ...
Yes.
So, the apparent
Tarapia Tapioco wrote:
We've recently seen FreeS/WAN die, not least due to the apparent
practical failure of Opportunistic Encryption. The largest blocking
point for deployment of OE always seemed to be the requirement for
publishing one's key in the reverse DNS space. ...
Yes.
So, the apparent
We've recently seen FreeS/WAN die, not least due to the apparent
practical failure of Opportunistic Encryption. The largest blocking
point for deployment of OE always seemed to be the requirement for
publishing one's key in the reverse DNS space. While most tech-savvy
people are able to get access
We've recently seen FreeS/WAN die, not least due to the apparent
practical failure of Opportunistic Encryption. The largest blocking
point for deployment of OE always seemed to be the requirement for
publishing one's key in the reverse DNS space. While most tech-savvy
people are able to get access
18 matches
Mail list logo