( just jumped onto the list )

nash <[EMAIL PROTECTED]> wrote:
> How do you feel this differs from a participant simply pre-agreeing on his
keys with the "passive attacker?"

There is not much difference, you are right.  What we described is also a
lot easier to detect ( are there actually ips signatures for this? ), but
easier to implement and coordinate.

> How does the threat differ from the participant simply forwarding the
plaintext on a separate channel?

The separate channel isn't necessary, that's the difference.

> I mean, no key exchange protocol is magical. If one of the parties is a
bad guy, then he can subvert the security objectives of the protocol every
time. What are you really expecting DH to do, here?

We are expecting the vendors who claim to sell highly secure equipment to
follow extremely simple sanitation procedures as recommended by the NIST ,
ANSI , and various RFCs.

> Blake-Wilson, et al., set out the authenticated key agreement problem
> in this way: ... entity i wishes to agree on secret keying information
with entity j. Each party desires an assurance that no party other than i
and j can possibly compute the keying information agreed.

> Your attack assumes that j is the "bad guy." That's not what Blake-Wilson
seem to be talking about.

I disagree.  They're supposed to protect themselves.  There is no assurance
that no other party can compute the keying information if the keys aren't
validated.  Buggy software can send invalid keys, for instance.

> This strikes me as sloppy academics at best, or deliberately misleading,
at worst. I hope you were merely excited and in a rush, but either way
you've thrown several red flags.

This characterization is unnecessary.  We are not a research organization
and I am not an academic.  We are simply pointing out that nobody is
following the recommendations.  I admit that the title of the blog post
could have been less inflammatory.

You also did not address the fact that DoS/MitM implementations don't need
to compute the secret, so the processing power required to run them is a lot

-Adam Bozanch
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.

Reply via email to