Talk:Opportunistic encryption

I do hate to bring up layering. Really.

Are the potential encryption modes learned in the source authentication process? Let's say, for example, two hosts are both capable of doing IPSec transport mode and SSL. How do they decide what to use if there are multiple options? If, in a given crypto protocol, there are different key lengths, timers, etc. -- do they negotiate?

Howard C. Berkowitz 19:28, 30 August 2010 (UTC)

Much of the complexity in IPsec is devoted to negotiation. At least choice of cipher and hash, which Diffie-Hellman group to use, and I'm not sure what else. The OE RFC simplifies some of that; always use 3DES and SHA-1.

FreeS/WAN OE makes that negotiation happen for the first IP packet to a destination. The packet is held while you check DNS to see if the other guy has a key there and can do OE. If yes, negotiate an IPsec tunnel. If not, either drop the packet or send it in the clear, depending on a policy setting.

Use of SSL is controlled by applications, typically the browser, choosing http or https. That is in principle independent of whether IPsec is in play, though of course the app might look at IPsec state before making its choice.

We have some discussion of using more than one encryption layer at Traffic analysis Sandy Harris 00:10, 31 August 2010 (UTC)

You are saying here, and probably should in the application, that OE first tries to do SSL as driven by the browser, and then tries to do IPSec if it can get the PKI information from DNS? OE is potentially at two levels? Howard C. Berkowitz 02:34, 31 August 2010 (UTC)

SSL/TLS is not usually opportunistic. There is one form of OE, used by mail servers, that uses TLS. If the right things are in the mail setup dialog, then a TLS connection is used for the actual mail transfer. I do not know the details.

Other forms of OE operate at IP level. They will affect anything above IP. The FreeS/WAN version wants authentication keys in DNS records. The IPv6 system mentioned uses another mechanism.

It is not "first tries to do SSL ... and then tries to do IPsec". Mail servers will try to do SSL-based OE if they are configured to; this fails if the other server does not support it. In general, the mail server does not know if IPsec is in play. It works with SMTP, possibly with the SSL-based OE extension.

IPsec gateways, typically at organisation borders, will try to do IPsec on any packets they have a tunnel configured for. OE IPsec gateways will try to create tunnels for every packet they see; this fails if the other gateway does not support it. Sandy Harris 06:01, 31 August 2010 (UTC)

Clarifying the lede?

Perhaps the lede needs to include the idea that this is an architectural concept, which may apply to different protocol layers/families? The article gives me the impression -- perhaps correct -- that OE will search from highest available layer to lowest available layer to find some means of encryption.

I thought it was clear, but the lede obviously needs to be rewritten. Your impression is incorrect. A given OE system applies at one layer and will encrypt there if an opportunity arises, that is if both machines have been configured for OE. Once both are set up, the rest is automatic. There is no connection-specific setup, so no need for the two administrators to co-operate on configuring the connection; OE can secure connections even where he admins have had no contact.

I'm not sure when I'll get to this. It is 6 AM here; first day on new job starts in a few hours. Sandy Harris 21:54, 31 August 2010 (UTC)

Gordian Knot

But doesn't public key with PKI scale linearly? Howard C. Berkowitz 17:10, 31 August 2010 (UTC)

Not it you have to configure each connection. A fully connected network with n machines has n(n-1)/2 connections. Sandy Harris 21:38, 31 August 2010 (UTC)