Re: [secdir] Recurring issues found during sec review

[Alan DeKok <[e-mail]>]

On Jul 23, 2019, at 11:15 AM, Salz, Rich <[e-mail]> wrote:
> 
> 
>> That is, every MUST should have an obvious action for when it is
>> violated.
> 
>      That's a good phrasing.
> 
> 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.