Subject: Error in Security Considerations in an RFC

From: Florian Weimer <[email-masked]>
Date: Sat, 13 Mar 2010 09:35:28 +0100

I've come across a RFC which basically says, "in order to do X safely,
perform checks Y before you do X".  It turns out that it's possible to
evade those checks.  What should I do about it?  I've already
contacted the author, and he says that no update to the RFC is
planned.  Should i just file an errata?  The problem is not really
critical, fortunately.

(The nature of the protocol makes it pretty much impossible to notify
implementers privately.)

---

From: SM <[email-masked]>
Date: Sat, 13 Mar 2010 01:36:32 -0800

Hi Florian,
>planned.  Should i just file an errata?  The problem is not really

The alternatives are:

    (i)  File an errata [1].  Only a few people will read it.  A few 
of these few people might fix their implementations if they can be 
bothered to do so.

   (ii) Write an I-D to document the flaw and propose a fix.

  (iii) Write a revised version of the specification as an I-D.

If the RFC was the output of a WG, you'll have to convince the WG to 
adopt your I-D for (ii) and (iii).  Alternatively, the I-D can be an 
individual submission.  You'll have to convince an AD to sponsor it 
[2].  It's not much of an effort to do (i).

Regards,
-sm

1. http://www.ietf.org/iesg/statement/errata-processing.html
2. http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html

---

From: Russ Housley <[email-masked]>
Date: Sun, 14 Mar 2010 12:16:07 -0400

An errata is the best way to have this type of change documented.  At
least it will be captured for people to consider, and if the document is
ever updated, it will serve as a reminder.

Russ

On 3/13/2010 3:35 AM, Florian Weimer wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: David Morris <[email-masked]>
Date: Sun, 14 Mar 2010 10:09:32 -0700 (PDT)

I sense from the earlier comments that there may be hesitation to
document the flaw for fear that such documentation would facilitate
exploitation before remediation is in place.

It that is a possiblity, public documentation should wait until some form
of private peer review can occur. I'm not speaking beyond my experience,
by my impression is that CERT provides a mechanism for recording these
sorts of issues allowing for review, etc.

My second suggestion, if the flaw is known to be implemented in released 
software, contact the security departments of the distributors of such
software.

---

From: todd glassey <[email-masked]>
Date: Sun, 14 Mar 2010 10:48:34 -0700

> ever updated, it will serve as a reminder.

Isn't this one of the risks with creating standards which authorize
their use in any form or any level of completeness???

I bring this up because people who are going to build evil code per se
are just going to do that and the IETF license will not stop them.
However those who just implement partial functionality under a lot of
IETF protocols have caused huge amounts of damage IMHO to both the state
of the security in IETF offerings and in other IP which is leveraged
against it.

Another issue is coming to light now and that is the standard-of-care
for the use of a protocol in production of anything.  These are things
we still laugh at here in the IETF but in places like a couple of the
Communications and CDE vendor's Legal departments they are not laughing
so loudly anymore.

This is reality - accountability is important and the integrity of the
standards process is equally important to the work that is created as a
joint engineering work project between those pursuing the standard.

Its about accountability in the bigger picture because things happening
inside the IETF standards process for better or worse, do directly
effect the world around them.

I have brought this up before that there should be in each RFC a
Statement of Use and a "Minimum Competency" (in regard to the minimum
set of features) as a requirement for use of the IP in the RFC to
implement a protocol.
>> evade those checks. 

To fix this you would have to submit a protocol to the IETF with a
specific set of constraints on it saying that "Any 3rd party
implementations of this Protocol Standard must implement the specified
minimum functionality to be licensed from the IETF"

>> What should I do about it?  I've already

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 14 Mar 2010 11:36:56 -0700

> exploitation before remediation is in place.

If one person can find it others will too...

> sorts of issues allowing for review, etc.

It's likely that remediation would have to proceed prior to revision of
docs, consider openssl, rh0, bgp ttl hack, tcp md5 protecting bgp etc.

> software, contact the security departments of the distributors of such

The would be good form. Of course when the number of people in a know
increases the likelyhood that someone malicious is likely to have that
information. Timely public exposure is important, the people with the
most exposure are not the vendors.