[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Certificate Policy Standardization


At 3:18 +1300 12/6/03, Peter Gutmann wrote:
Stephen Kent <kent@xxxxxxx> writes:

Citing the critique from the Counterpane analysis of Ipsec and IKE from 5
years ago is a nice touch, but you should be aware that the non-IKE
criticisms were largely refuted in messages on the IPsec list.


Well that's a marvellous strawman you've demolished there, but you still
haven't addressed the original point I made, which is that without a
rationale, without explanations of difficult-to-understand points, a complex
standard is in trouble.  In fact you've pretty much agreed with my comments:

I doubt that :-)


  Unfortunately, the folks who performed the analysis were not protocol
  experts. They made assertions of what was wrong and how it should be fixed,
  and in most instances THEY were wrong.

What we have here is an example of knowledgeable people in one area, critiquing a document in an area that is not within their expertise. Most IETF standards are written for developers, not for end users, system administrators, etc.

Without a rationale and implementation notes to guide them, there was no way
they could understand the spec, so they ended up analysing something that was
different from whatever it was the spec was trying to describe.  What was
refuted was the analysis of the way Bruce thought IPsec worked, not the fact
that the spec is confusing, ambiguous, and contradictory.

Nonsense! The example that prompted my response was the failure of MS implementors to do what the standard clearly stated, and what essentially ALL other implementors DID manage to get right. Why the MS guys failed here is open for debate. But the aspect of IPsec (not IKE) that they got wrong was not ambiguous, and it followed the practice that is used in essentially ALL other access control list systems for 25+ years. Also, as I noted in my initial response, most of the Counterpane criticisms were related to IKE, not to IPsec per se.

Your comments do however raise one question: If (as you say) the intent wasn't
to create an IPsec for dummies, who exactly is the target audience?  It's not
the average person, it's not techies and sysadmins, it's not cryptographers,
it's not security researchers, just who *was* this written for anyway?  Your
first message implied that the only people capable of understanding IPsec are
people who already understand IPsec before they start.  So the target audience
for the IPsec spec is "Anyone who's spent the last 5-10 years on the IPsec
list"?  What happens when an outsider has to implement IPsec?   (Well, I think
that's obvious from real-world experience with IPsec deployment when 2 or more
different vendors are involved).  Is everyone who needs a technical question
on IPsec answered expected to track down IPsec list members and ask them, like
I did recently when I needed an answer to a simple yes/no question?  What
happens when the last person who was involved in the IPsec design process
retires and there's no-one left to ask about all the stuff the spec doesn't
tell you?

As I noted above, IETF standards are written for developers. Other authors typically write books for users, sys admins, CIOs, etc.

To get back to the original point about including explanations and
implementation guidance in specs, a spec is difficult now and downright
dangerous in the future when there's no-one left to explain all the bits the
authors never bothered writing down.  Consider as a nice counterexample the
DNS SRV spec.  It starts with the usual MUST/SHOULD/MAY stuff.  All the
features are clearly explained (not just "It does X" but "It does X because
Y").  There's advice for administrators.  There's pseudocode for certain
processes that people might find confusing.  There's a complete worked example
(I cut & pasted it into a zone file for testing).  You can implement it
straight out of the spec in about half an hour (OK, it's nowhere near as
complex as IPsec), and it works the first time.  With every server I could
find (and that's definitely nothing like IPsec).

The reason why it did that is because the authors didn't start by deciding
"We're not going to write a DNS for dummies", but because they wrote a spec
for implementors and users, which is why anyone can pick it up and write a
fully functional, interoperable DNS SRV implementation from it.  Can you do
that with IPsec, or PKIX?

2782 seems to be a well written RFC, but it is far from typical. In fact, it is very unusual in this respect. If the IESG wants all RFCs to be of this form, then they can require a different style of documents. However, the trend has not been to call for this style of writing, and that's not suprising, since not other standards body writes documents in this way either.

So, what's the bottom line? Could IPsec be better documented, yes. Is it a bad spec, no, not compared to most others in the IETF, ANSI, IEEE, and ITU realms. Did the implementors who screwed up the SPD management interface for MS products do so because RFC 2401 does not provide rationale for the ordering requirement? Possible, but unlikely, since so many others managed to get this right, and without recourse to the authors or the mailing list.

Steve