Subject: Re: Certificate Policy Standardization

From: [email-masked] (Peter Gutmann)
Date: Sat, 6 Dec 2003 03:18:57 +1300

Stephen Kent <[email-masked]> 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:

  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.

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.

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?

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?

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Dec 2003 15:24:34 -0500

>standard is in trouble.  In fact you've pretty much agreed with my comments:

I doubt that :-)

>   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.

>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.

>retires and there's no-one left to ask about all the stuff the spec doesn't

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

>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