Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH

From: Paul Koning <[email-masked]>
Date: Mon, 10 Jul 2000 12:10:47 -0400 (EDT)

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

 Stephen> Jim, I support Denis in his desire to have the TSA check
 Stephen> everything it can (syntactically) in a request.  Not
 Stephen> checking allows the TSA to sign tokens that are just broken.
 Stephen> We have seen many examples of broken certs signed by CAs, so
 Stephen> I think it worthwhile that we put language in RFCs to
 Stephen> require, where possible, that appropriate consistency checks
 Stephen> be performed.  RFC 2459 has a few statement about
 Stephen> relationships among extensions, which gets to the same
 Stephen> concerns.  We could put in more, or collect them in one
 Stephen> place, and make for a better document.

 Stephen> I may have lost track of the counter argument here.  Why
 Stephen> would one not want to have a TSA do the best possible job
 Stephen> when it comes to ensuring syntactic consistency re its
 Stephen> inputs?

The Internet protocol design rule is "be strict in what you send,
tolerant in what you receive".  It has been known for decades that
this is the correct rule.  (That doesn't keep some other standards
bodies from ignoring it, unfortunately.  Then again, there are still
standards bodies that use two-way connection setup handshakes...)

Protocols should check those invariants that have to be valid for
correct operation to result, or for interoperability to be possible.
Checks beyond that are counterproductive.

In particular, the more you check, the more often you have to ECO your
specs and your implementation as new extensions are registered.  And
the more often you have to release bugfixes.

    paul

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Jul 2000 09:53:37 -0400

><snip>

>standards bodies that use two-way connection setup handshakes...)

The quote you cite is based on advice from the late Jon Postel, 
someone I knew well for over 20 years, and with whom I served on the 
IAB for over 12 years.
As I acknowledged earlier, it is appropriate advice in general, but 
not necessarily appropriate for security protocols, and it certainly 
is not an "Internet protocol design rule." Felexibility in input 
acceptance in security protocols provides attackers with more options 
for attacks, hardly a desirable feature.  Our goal is to constrain 
interfaces so as to better understand them and the security 
implications of various combinations of input parameters. So, merely 
citing this general advice is not a basis for making such decisions 
in security protocols.

>Checks beyond that are counterproductive.

If we can be confident that a failure to check certain inputs will 
not result in adverse effects under any circumstances, then we need 
not check them.  However, when a TTP such as a TSA is signing a token 
it is not clear that this is true.

>the more often you have to release bugfixes.

Agreed.  But our primary focus is security, so the issue is what 
constitutes the right tradeoff.  New hash algorithms do not arise so 
quickly that a TSA can't anticipate them and the associated size of 
the hash value. Looking at the time it takes for a standards bodies 
to approve such things and assign OIDs, this does not seem hard. 
Also, we're not talking about changes to client software, but rather 
server software/hardware, which is much more amenable to such change 
management.

Steve