[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: All this tweaking is nice, but...
I don't know but I think we wouldn't be doing all this tweeking if the original drafts
had been well thought out and the NRL "reference" pile of... code... made sense
for more than just the base transforms which, lets face it, made no sense.
You must agree that less than six months ago when we had a base transform
that depended on changing the behaviour of MD5 and sets of documents that
said "oh and key management will handle that" when key management didn't
exist really, and we had drafts with material changes being introduced AFTER
last call and etc. etc. etc. we were in pretty bad shape.
I would argue that this process is broken and that the tweaks are necessary to
produce something that is secure and that does make sense and is extensible.
The drafts/RFC we have now are not really any of the above.
64 bit replay? great for alignment, bad for security/stupid to implement.
key hashing by transforms based on ISAKMP attributes? what? secure maybe, extensible? what?
documents to resolve documents? When is that ever right?
variable length optional fields in the middle of fixed headers?? WHAT! -10. I can hear my compsci
120 prof laughing now..
I would call all of the above "honest to God BREAKAGE."
A lot of us "Write Code (TM)". A lot of us write for a market that cares
about quality and security. A lot of us write code that has to be maintained
and costs money if it is broken. A lot of us will have to live with this pile of ..
code .. for a long time in the future. We want this to work, to be secure, to
be really extensible and we don't want to support broken, ill-conceived trash
that we'll have to maintain forever because some customer will not upgrade.
That's the difference between the NRL hack ah oh sorry, code and what
we are doing. I don't think we require perfection, we just require that it
makes sense and will actually achieve the goals we have for our products
and our customers.
Rob Adams
Cisco Systems
----------
From: Dan McDonald[SMTP:Dan.McDonald@Eng.sun.com]
Sent: Wednesday, March 19, 1997 9:25 AM
To: ipsec@tis.com
Subject: All this tweaking is nice, but...
Hello folks in IPsec-land!
I've been seeing a lot of last-minute tweaks lately on the list. As someone
who Writes Code (TM), and as someone who's helped build some of the earliest
versions of IPsec, I just have one question: WHY?
Most of the ones I've seen recently seem extraneous (we can argue until we're
blue in the face about if truncation is stronger, but the critical question
is if non-truncated is BROKEN?), and others are made for reasons that don't
take into account the big picture (code needed to parse variable-sized replay
counters is lost in the noise compared with the HMAC calculations, so don't
go whining about performance).
I'll bet small sums that some of what's been popping up on IPsec is the
result of some of the AIAG stuff. It's good that stuff like AIAG happens,
but you guys can't forget that some of us aren't doing (or can't do) AIAG yet
for _varying_ reasons.
A few things to remember folks:
1.) The IP Security Architecture is EXTENSIBLE. This means if
something's really broke, you can obsolete the current draft
with a new one. Apart from changes derived from Bellovin's
summer USENIX paper (some of which, mind you, merely involved
following the spec), I haven't seen anything after those changes
(Combined ESP, replay) that fixes honest-to-God BREAKAGE.
Let's go with what's there, and create NEW drafts for some of
these new approaches.
2.) The KISS principle. Yes, we can't leave gaping holes, but if
there are no gaping holes, let's not go changing for change's
sake! I'd suggest to everyone on this list a re-reading of _The
Mythical Man-Month_ by Fred Brooks. And if you've never read
this seminal work, for crying out loud find a copy.
3.) Let's not create a separate implementors list the way IPng did.
I don't get AIAG-type mail, because I'm unable to show up for
now. I'm sure I'm not the only one, though. Spec writers need
to hear about implementation experience, and implementors need to
hear the writers' rationale(s).
4.) We're in the risk reduction business. The only perfect security
is the good ole-fashioned airgap firewall, or something else that
keeps you from moving bits. (If anyone calls your network
"truly secure" be afraid, be very afraid.) If we reduce the
vulnerability, we're doing well.
Alright alright, I'll climb down off my soapbox now.
ObPlug: My updated internet drafts are in the I-D queue currently.
Watch for them.
--
Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT
Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S!
Phone: (415) 786-6815 |"rising falling at force ten
WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush