Talk:Opportunistic encryption: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Sandy Harris
imported>Howard C. Berkowitz
Line 13: Line 13:
: 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.
: 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]] [[User:Sandy Harris|Sandy Harris]] 00:10, 31 August 2010 (UTC)
: We have some discussion of using more than one encryption layer at [[Traffic analysis]] [[User:Sandy Harris|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? [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 02:34, 31 August 2010 (UTC)

Revision as of 21:34, 30 August 2010

This article is developed but not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
To learn how to update the categories for this article, see here. To update categories, edit the metadata template.
 Definition A technique whereby computers can set up their own encrypted connections, without any connection-specific setup by an administrator. [d] [e]
Checklist and Archives
 Workgroup category computers [Editors asked to check categories]
 Subgroup category:  Security
 Talk Archive none  English language variant Canadian English

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)