[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bruce Schneier on IPsec
> > ...IPSec is clearly being deployed and I think you will find
> > that a significant percentage of Internet traffic will be IPSec protected in
> > just a few short years. And this is very good.
>
> Ah, but is it? That is an assumption, not a definitely known fact. Weak
> security is worse than none at all, because it breeds overconfidence.
> Imminent widespread deployment of IPSec would be better news if there
> weren't so many concerns about just how strong its security really is.
>
>
Many things would be better in an ideal world.
But given the many constraints of the dirty real world, I think that
we can consider ipsec as a suitable protocol for use to protect IP traffic.
It could have been better, it could have been simpler, it could have
been more elegant, it could have been better documented, it could have
included some better design decisions, it could have corrected known
weaknesses. But, in spite of all these "could have", ipsec/ike IS a very
valuable protocol. Not just the best available alternative but a good
protocol in many senses.
The analysis work by Ferguson and Schneier is an important document, but
beware of reaching the wrong conclusions. The document discusses
the faults of the protocol not its merits. Still it shows no fatal
design aspect among those checked by the authors, nor it
presents new significant information not previously known to the WG.
The authors seem to be personally disappointed.
That does not mean that the protocol is inappropriate.
In my opinion nothing said there should stop ipsec deployment.
(And, believe me, I had and have many complaints about the protocol,
including many of the issues presented in [FS]; and I have been
repeatedly frustrated by the process and bad idea of "cryptographic
design by rough consensus". But none of these considerations are
sufficient to invalidate the resultant protocol or make it inherently
insecure.)
The protocol and its many aspects still requires a lot of analysis and I hope
that other security-analysis people (including cryptographers) will keep
working on this. Too bad, that so few people from this area joined
us when designing (or, more accurately, fighting for) this protocol.
Hugo
PS: After defending ipsec for once, I'd like to see also openess in the group
for changes that significantly improve the quality of the protocols
even at the cost of hurting some existing implementations (and the sooner
things are fixed the better).
We can start with many issues that [FS] point out (and other that
were discussed in this list) that can be "resolved" by textual clarifications,
and then proceed to the fixes that also require changing the
"bits on the wire".
Follow-Ups:
References: