On 12/30/05, David Schwartz <[EMAIL PROTECTED]> wrote: > > > Actually, he did answer my question precisely. > > > I asked if there was a way to create an ephemerally (i.e., > > unauthenticated) encrypted session, after which I could exchange > > certificates. > > Correct. But how would an encypted session with an adversary help you?
Because to accept a connection and negotiate encryption parameters is a computationally-intensive task, there's no way it could be called 'just a fluke" or "not taking due diligence to protect your own information". My threat model is "someone on a network that I use is writing a piece of network-related software that isn't working properly, so he uses a packet capture device [of whatever type] to help him debug, and inadvertently catches snippets of a conversation that I'm having that I would prefer him not to know." Just because I'm roommates with someone doesn't mean that I want him to know my deepest, darkest secrets. > > My intent is to thwart Eve (the eavesdropper... i.e., the sysadmin who > > is doing network monitoring, as an example). I am aware that Mallory > > (the malicious peer who wants to be the MITM) could obtain the > > credentials on the renegotiation; however, that requires an active > > attempt to violate the security of the connection [and thus the > > 'secrecy' of the contents of the certificates]. > > Exactly, so it doesn't help you. It helps me, because before I exchange certificates, the connection is already encrypted. This would require more than a 'passive monitoring', but rather an 'active attempt to interfere'. > What you really want is two rounds of identification. One with a > certificate that doesn't contain any information you don't want to make > public, just for authentication. Once you have authenticated, you can then > present the certificate that contains the information you want to control. I've been dealing with cryptography for 13 years. Please don't patronize me by attempting to tell me what I want. While that would deal with the Mallory situation referenced above, I'm NOT TRYING TO PROTECT AGAINST MALLORY. Sheesh. One would think that "I am aware that..." would suggest that the possibility has already been considered and found to be a non-issue. > I strongly caution you against adopting any threat model that involves > treating eavesdroppers differently from MITMs. It's easy enough with today's > technology to provide the same protection, so it's usually foolish not to. > YMMV. MMDV. > You are still volunteering the information to any unauthenticated > entity > that requests it. If the issue is really "it passed over my network > unencrypted" how is "you give it to anyone indiscriminately" any different? > > I guess I don't know what your threat model is. If it is impossible to > authenticate with any other method, because you really do want to give the > certificate to anyone, but only if they explicitly ask or use subterfuge to > get it, maybe it could make sense. > > Just understand that you have no actual security, just a legal > argument. > It's like a sign that says "locked" rather than a lock. > > DS I'm being vague with my threat model on purpose. There are reasons I'm not concerned with MITMs. Really. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
