Re: [secdir] Recurring issues found during sec review

[Alan DeKok <[e-mail]>]

On Jul 23, 2019, at 9:46 AM, Roman Danyliw <[e-mail]> wrote:
> 
> Hi!
> 
> As an IESG initiatives, each of the areas is pulling together a list of "recurring issues" found by their areas during area review (e.g., secdir, iotdir, genart, opsdir, tsvart) and IESG review.  The intent is to provide informal, but not comprehensive, guidance to draft authors and their WG chairs with the intent to find issues earlier.  Ben and I made the following initial list:
> 
> https://trac.ietf.org/trac/sec/wiki/TypicalSECAreaIssues

  One issue I don't see covered is "what happens when things go wrong?"  This isn't quite "Broken Constraints", but it's close.

  The temptation is to describe how things *should* work.  But that isn't good enough.  In the real world, we need to describe how to handle the failure conditions, too.

  When specifications says "When a server receives X, it does Y", what happens when the server *doesn't* receive X?

  What does it do?  How are errors handled?

  Saying "When X do Y" is very much an "if" condition, even though it is not phrased as such.  The solution is to about handle the "else" case to every "if", as with the following example:

	IF a server receives X
	THEN
		do Y
	ELSE
		do something else

  IIRC, the above behaviour is required in medical software.  "No IF without an ELSE".  I believe it should be required for protocol specifications, too.

  As an implementor, I can't count the number of times I've run into this issue.  Reading the specification is nice, but it doesn't give me enough information to create a robust implementation.  That experience has influenced the standards I write, so they pretty much all have an "else" for every "if".  And it's a repeated comment I have for documents I review.

  Alan DeKok.