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 the 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)

Did some. Sandy Harris 11:47, 1 September 2010 (UTC)

I've done more. Any comment now? Sandy Harris 00:50, 12 September 2010 (UTC)

Maybe what I'm not getting

How does OE handle authentication? I'm now picturing that the called OE node either looks up the purported ID to get credentials, or the connection request carries session encryption information. Neither, however, would seem resistant to masquerade. Howard C. Berkowitz 23:43, 13 September 2010 (UTC)

Reading further, it sounds like you trust the user ID. In FreeS/WAN, at least, one does a reverse DNS and if there's a signed entry, that's adequate for the level of security? Howard C. Berkowitz 11:36, 14 September 2010 (UTC)

Does text I recently added, last sentences of first para of "OE for IP" section, answer that question? Sandy Harris 11:46, 14 September 2010 (UTC)

It helped me formulate the question above. Perhaps the essence of both, which seems to be that OE is not a defense against active attack, belongs in the lede. I don't want to equate it to BTNS, but it seems to be a fair statement that OE is not going to be as strong, although easier to administer, than a system without PKI or PGP-style credentials. There's a subtle suggestion now that OE is a substitute, not a tradeoff. Howard C. Berkowitz 12:37, 14 September 2010 (UTC)

OE with proper authentication is intended to be a defense against active attacks. The defense is not entirely reliable without DNS security. The suggestion should not be subtle; I'll rewrite to make it clearer. Sandy Harris 22:16, 14 September 2010 (UTC)

Sometimes I can be dense. Still, this whole interchange is convincing me of the importance of the article. I'm finding it most difficult to follow the requirements for authentication, or if non-authenticated communications are permitted. Howard C. Berkowitz 22:31, 14 September 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)

I'm assuming the PKI contains the DOI and timer, etc., parameters. What else has to be configured? The number of connections is independent to the number of configurations -- there might be one configuration assuming any endpoint can orginate or accept connections.

Now, if "configuration" is the list of permitted partners, that might be a feature rather than a bug.

So far, I'm afraid, I don't understand what OE is doing, differently from other things. Howard C. Berkowitz 22:25, 31 August 2010 (UTC)

Getting closer

The words about reverse DNS in OE for IP are a crucial example. I'd suggest an extract, diagram, or both in the lede, showing this as representative.

While the words aren't right, I'm beginning to think that "OE is a means of minimizing the administration needed for encryption, by building on things already present in general Internet infrastructure, such as [reverse] DNS."

--Howard C. Berkowitz 17:21, 17 September 2010 (UTC)