Talk:Opportunistic encryption
Jump to navigation
Jump to search
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)