> 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".
I totally disagree. You volunteer the information to anyone who asks.
How
is that "taking due diligence to protect" anything?
> 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."
Then XOR all the data with 0x42.
> Just because I'm roommates with someone doesn't mean that I want him
> to know my deepest, darkest secrets.
That's what authentication is for. That's why you don't volunteer
information to anyone who asks.
> > > 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'.
No, it would not. Making a connection to a service that offers
information
for the asking is not an 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.
This is a nonsensical answer. This is like saying you shouldn't use a
lock
to keep out car thieves because a lock will also keep out people who aren't
car theives and you aren't trying to protect against them.
This will keep out Mallory. You don't want Mallory in. So that this
protects against Mallory is a huge plus. It deals with one threat model that
your solution does not. How can you possibly argue that this is a minus?
> > Just understand that you have no actual security, just
> > a legal argument.
> > It's like a sign that says "locked" rather than a lock.
> I'm being vague with my threat model on purpose. There are reasons
> I'm not concerned with MITMs. Really.
Then I'll just reiterate to anyone reading this that the advice you are
getting is specific to some special circumstance that we cannot even
evaluate. We only have your word that it even applies to your situation, and
it certainly doesn't apply to any typical situation.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
