Re: RESEND: Thoughts on identity attacks

[Dan Harkins <dharkins@tibernian.com>]

On Wed, 06 Feb 2002 11:05:52 PST you wrote
> Paul,
> 
> Perhaps the fact that there were no responses suggests that not enough
> people think it is important.  Let me introduce a counter view.  I not only
> think it is not important but I think that pursuit of this goal risks
> further complicating an already too complicated protocol.  I really think
> our energies are best directed at more important issues.

I don't think you understand the context here. It is not to add some new
feature to "an too already complicated protocol", it is to determine what
a new protocol should/must have.

As far as "already complicated protocols" go the one we're stuck with now
already has a mode of protecting both identities from passive attack and
also one that protects both from active attack (provided the Initiator
already knows the Responder's public key). So this discussion is about
_simplifying_ things by removing what is not needed not further complicating
things by adding something new.

> After a year of discussions on requirements with product management of all
> the big VPN manufacturers, I have never even once heard that identity
> protection or 'obfuscated identities' are a requirement.  Of course as the
> chair of the VPNC you may know much more about these matters and I would be
> delighted if you or someone could point me at data that suggests that this
> is a requirement among manufacturers and/or the user community.

Product management of all the big VPN manufacturers? Aren't those the same
ones who said, "We know it's insecure but it's easy to deploy and customers
want it so shut up and implement it." 

Product management from any company do not frame debate here. On the other
hand if someone from product management from a big VPN manufacturer wishes
to add his or her points of view it would probably be better done directly
and not through rumor.

> I think most companies find PKI itself too complicated.  Both VPN solution
> providers and large users seem to prefer to stick with shared passwords
> rather than build support for or manage a PKI.  Things like PKIX compliant
> path validation, CRL / OCSP support, certificate life cycle management,
> enrollment, etc. scare away all but the most intrepid.  At this point I
> would NOT recommend adding any more features and would only consider
> removing/simplifying some.  After there is a large population of users we
> can learn from actual security breaches and address security concerns that
> arise - as they arise - in future enhancements to the protocol.

There is no support for shared passwords with the current protocol so I'm
not really sure what you're proposing here. Limiting the feature set to
something that is not there while simultaneously recommending against adding
new features? 

  Dan.