Subject: [secdir] Recurring issues found during sec review

From: Roman Danyliw <[email-masked]>
Date: Tue, 23 Jul 2019 13:46:37 +0000

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

Welcome feedback and refinement!

Regards,
Roman and Ben

---

From: Alan DeKok <[email-masked]>
Date: Tue, 23 Jul 2019 10:07:55 -0400

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Jul 2019 10:14:11 -0400 (EDT)

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

Right. In our terms that would be more in the sense of, the client MUST
send X. If the server receives a request without X, it MUST do z.

That is, every MUST should have an obvious action for when it is
violated.

And we have the weaker version with SHOULD. For every SHOULD in the
document, the authors should have at least one example of where the
SHOULD case exception is valid. If they cannot come up with that
exception, the SHOULD should be a MUST.

In a way, this process is running a fuzzer against your proposed
specification.

Paul

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Jul 2019 10:24:07 -0400

Please add "Do not make up your own cryptography".  I have not seen it in a while, but when I see it, it is poorly done.

Russ

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Alan DeKok <[email-masked]>
Date: Tue, 23 Jul 2019 11:05:23 -0400

> That is, every MUST should have an obvious action for when it is

  That's a good phrasing.

> exception, the SHOULD should be a MUST.

  I agree.

  Alan DeKok.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Jul 2019 15:15:42 +0000

That's a good phrasing.

I strongly disagree.  It turns every MUST into something that only the recipient must act on.  The burden of the protocol should be on both sides to act correctly, and one side should not be constrained to behave a particular way if the counter-party misbehaves. Another reason against this is that it tends to result in naïve behavior such as oracles or "name not found" being distinguished from "wrong password"

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Jul 2019 11:33:18 -0400 (EDT)

On Tue, 23 Jul 2019, Salz, Rich wrote:

> I strongly disagree.  It turns every MUST into something that only the recipient must act on.

Unless it is MUST ignore ?

>  The burden of the protocol should be on both sides to act correctly

Indeed, the document would already state not to send malformed data. But
the responder/server will be the endpoint dealing with those violations.

> , and one side should not be constrained to behave a particular way if the counter-party misbehaves. Another reason against this is that it tends to result in naïve behavior such as oracles or "name not found" being distinguished from "wrong password"

I think we are not saying different things. If the action of a MUST is
not obvious (eg drop packet), and there are security issues into giving
too specific error codes as the example you bring up, it is precisely
why the document should tell you what to do. I'm not saying every MUST
must have a specific and immediate sentence following saying what to do.

For example, IKEv2 has a very limited set of error codes specifically
to cover your concern here. INVALID_SYNTAX, AUTHENTICATION_FAILED and
NO_PROPOSAL_CHOSEN. With the latter one being the kitchen sink of
errors.

Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Jul 2019 15:37:11 +0000

>    > That is, every MUST should have an obvious action for when it is

...

   > I'm not saying every MUST

Okay.  From my quotes above, I hope you can see why I misunderstood you.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 23 Jul 2019 11:51:08 -0400

> I strongly disagree.  It turns every MUST into something that only the recipient must act on.

  If one party MUST send X, then there's not really any benefit to saying "or else...".  That party sends X, or it's not compliant.  If that party ignores the MUST, then there isn't any point in having an extra clause that says "or else MUST do ...".  They'll just ignore that, too.

  The issue is with the other party.  If the other side MUST send X, then what does the recipient do when it doesn't receive X?  That should be stated clearly.

>  The burden of the protocol should be on both sides to act correctly, and one side should not be constrained to behave a particular way if the counter-party misbehaves.

  If it's about security, then absolutely one party should be constrained to do something *safe* if the other party misbehaves.

  Another example is sending packetized data over TCP.  i.e. sequences of "header, length, data".  What happens if the recipient can't decode a particular message?  I've seen long arguments where people say "the recipient should try to continue".

  OK... HOW?  If the header / length is malformed, then we have absolutely no clue how to decode the next set of octets we receive.  The only safe thing to do is to close the connection, and start over.  Hence phrases like "the recipient MUST close the connection if the message is malformed"

  I think the "else MUST" phrases really only apply to recipients.  They're not in control of the data that they receive.  And they must do *something* with that data.

  Perhaps the phrasing could be "if the sender MUST do X, then the recipient MUST be able to deal with situations where that doesn't happen".

> Another reason against this is that it tends to result in naïve behavior such as oracles or "name not found" being distinguished from "wrong password"

  I'm not clear how that applies.

  Alan DeKok.