On Mon Oct 6 10:55:10 2008, Jonathan Schleifer wrote:
Am 06.10.2008 um 11:17 schrieb Dave Cridland:
Right, you'd ideally need a SIGMA-I, no SAS at all, and some
method for verifying the police's public key. But since the
esession protocol provides no method for doing that short of
transferring the entire public key using a side-channel, I'm not
entirely convinced it helps much beyond moving the problem about,
and using a big chunk of static data with no agreement on
implementation instead of a short variable string.
ESessions also offers public keys.
Yes, as I've already indicated. Thinking further, it'd be possible to
simply have a fingerprint of the public key - ie, a hash of it - and
ask the user to verify that. Again, though, the problem here is that
the security of the esession relies on the security of the manner in
which the public key or fingerprint thereof is transmitted - if an
attacker subverts that channel to substitute his own public key, then
he can subvert the esessions channel itself.
Therefore I'd hold that these are equivalent, in terms of security,
with the SAS code.
FWIW, a public key (or fingerprint) is simpler to disseminate, but
the only way I can see for doing so would be to use a
TLS-authenticated web page. A problem here is that it might be
possible to correlate esession negotiations and IP addresses, thus
causing the security leak you were complaining about much, much
earlier in the thread.
Btw, why do you come up with ESessions in a thread that isn't about
them? I thought we already had that flamewar? Is it necessary to
start it again?
There is no flamewar here. You appear to disagree with me about what
esessions offers, and what security it is providing. The only reason
this came up was because I happened to mention a particular case
where the use of IBB would be useful to avoid leaking identity - as
you were arguing for - and in what I described as a momentary aside I
suggested that esessions couldn't provide assymetric authentication.
You disputed this, and I agreed that it was possible, if and only if
the side-channel used to exchange the SAS code (or public key itself,
if you prefer) had the requisite properties. You agreed with my
revised conclusion, but insisted that all my arguments were wrong,
and that I "clearly" did not understand SAS etc, which probably does
count as a flamewar, but not really on my part. Still, I've thicker
skin.
I'm not really clear why you're arguing this case, given that you
appear to agree it's not really what esessions sets out to achieve
anyway, but it certainly appears that one of us has some
misunderstandings about the protocol, and I think it's important to
figure out who.
So what you're saying there, then is that the SAS exchange is
worthless, because there's no way for me to prove that, once I've
given you a SAS code, whether or not it matched, irregardless of
whether or not the other party continues, and therefore whether or
not the session is secure.
Why is it worthless?
Oh, I don't think it is. I think it's symmetrical, which is entirely
different from worthless. I'm saying that your statements, taken as
truth, would prove that esessions is indeed worthless. This is why I
disagree with your statements.
If I talked to the other person on the phone for example and let
him tell me his SAS and it matches mine, I know that he's the
person I think he is.
Assuming that the phone call is not subject to an MITM attack and
that it's identifiable, which I'm happy to go along with. (Although
for the purposes of stating the obvious, unless both caller-id works,
and the phone number itself has been exchanged by some relatively
secure mechanism...)
He knows it's me because he talked to me on the phone and I
assured him to have the same SAS.
This is where your previous assertions appear to be in conflict. How
does he know you weren't lying when you said it matched?
Under what circumstances, in your opinion, does exchanging a SAS
code for a session prove anything at all, and what does it prove?
See above.
Yes, you're actually agreeing with me that the method for verifying
the identity of the endpoints is to use a side-channel for SAS
exchange that identifies them, and using those properties and the SAS
exchange to assume an equivalence between that side-channel and the
esessions channel itself - that is, the only mechanism of obtaining
an asymmetry in terms of the security properties is to use a
side-channel which is itself assymetric.
Now, you appeared to dispute this right at the beginning of this
thread by categorically stating that "Many people have authenticated
me, but I haven't authenticated them." Now I'm proposing that you did
authenticate them, although you may have chosen not to record that
authentication or otherwise take action. You asked me to explain
this, and I think I have.
If you still assert that your authentication was only one way, could
you now explain how this was achieved, and in particular, what the
side-channel used for SAS was, what its security properties were, and
what the resultant security properties of the esession were?
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
