Subject: [MSEC] Re: MMD or GSAD

From: Ran Canetti <[email-masked]>
Date: Sun, 15 Jul 2001 00:42:43 -0400

Thomas,

> From [email-masked] Sat Jul 14 15:49:12 2001
> 
[snip]
> 
> I also realize that an RFC that simply pronounces that some
> state-information
> belonging to one protocol (eg. IPsec) must not be accessed/modified
> by other protocols, does not guarantee anything in the implementation.
> That is, saying X in an RFC does not guarantee the coder will do X.
> At the most, we can say that if a developer does modify state X,
> it will result in a "less-secure" implementation.
> 
> Thus, the documents may say, for example, that IGMP *must not* modify MMD,
> but can read it.  However, a human implementor may make a mistake
> and in fact corrupt the MMD.  This an implementation-quality issue,
> not a design flaw.

I think your approach is mistaken.
Since our goal is to guarantee also security and not only interoperability,
it is the duty of the standard to instruct the implementors on the 
"do"s and the "dont"s, even when this does not directly relate to
interoperability. A standard that leaves behind a spec that invites
compliants-yet-insecure implementations by innocent implementors 
is a bad security standard (even if it can potentially be implemented 
in a secure way).

Similarly, an implementation has the *obligation* to follow the
instructions of the standard, even if they do not have to do with
interoperability. For instance, an IKE implementation that always chooses a
secret exponent 1 for the Diffie-Hellman exchange cannot call itself
compliant with the IKE standard, even if it interoperates with all existing 
implementations.

In my mind, this is a central point where security standards differ from 
other IETF standards.

Ran

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 16 Jul 2001 10:23:26 -0400

>I think your approach is mistaken.

No Ran, I think you are misunderstanding what I meant.

>interoperability.

Yes, the RFCs can say the "do's" and "don'ts", but that will not guarantee
the quality of the implementation (from a security perspective).
That's simply my point.

>A standard that leaves behind a spec that invites

Hmmm, I don't think I said this ...:)

My point is that MSEC is not an academic exercise.  We have limited time.
We cannot worry about everything (especially a "complete" specification,
whatever that means :)

>interoperability.

Obligation to whom?  Seriously, the best expected is an interop at bake-offs.
Sorry if I sound skeptical.

>For instance, an IKE implementation that always chooses a

Yes, when it comes to specific self-contained algorithm parameters
like DES or DH, it is easy and do-able.  When it comes to system
designs (like GKM), then things get more complicated :)

thomas
------