[kelnage]

I would argue that the reason protocol errors are perceived to be "quite rare" is because the security guarantees that many (most?) security protocols offer are usually under-specified, if at all. When auditing protocols, analysts often have to infer what properties a user might expect.

A great example of this would be [1], where a number of ISO-standardised authentication protocols failed to give even the most basic authentication properties. And this kind of issue isn't limited to ISO - the same kinds of issues appeared when analysing TLS, Signal, and others.

The problem is that implementation errors are usually more clearly violations of confidentiality (i.e. it is obvious that an attacker is able to access something they weren't supposed to) - so they are generally held to be more valuable - and hence more eyes spend time looking for them.

(Disclaimer: I am doing a PhD in this field with Prof Cas Cremers, which might bias my views on this subject a little)

1. http://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/B...

[wuch]

What issue do you refer to in context of Signal protocol?

[kelnage]

Sorry, I didn't make myself clear there. Under-specified security properties. Although they (and TLS, honestly) do a better job than others, in their protocol documentation they really don't go to any lengths to describe what actual security the protocol provides - just that it is "secure". This makes verifying these protocols nigh impossible - and usually you end up with the analyst having to reverse-engineer what security properties they think the designers wanted the protocol to ensure.