I'm not sure that you're actually disputing my statement at all.
Your main case there is software developers failing to do protocol design, which is exactly what I'm saying is a bad idea if they don't happen to be independently expert in it.
The reality is these situations would be a whole lot easier to resolve if people actually respected the expertise of each other. This works in all directions, but recent bugs show a definite weakness in terms of respect given towards relatively basic software engineering practices.
I may have been unclear: I am claiming that you cannot be a good protocol designer without sufficient expertise in cryptography AND you cannot be a good implementer without sufficient expertise in protocol design (I have updated my OP to add an instance of an implementation bug caused by insufficient knowledge about protocol design as well: TLS timing attack).
You could make the argument that if the implementer has to know anything about why the protocol or crypto works then the spec is poorly specified.
Certainly it helps to have a minimum of appreciation of the other parts of the domain, but I think you greatly overestimate how important that is for the kinds of problem we've been seeing lately.
In any other field, I would agree with that assessment. In the world of crypto, with side-channel attacks on the sound of your keyboard as you type, I think that having domain knowledge is essential for any implementer.
You could make that argument, but I will join with mehrdada in disagreeing with it.
It's possible that more vulnerabilities are caused by programming errors than by protocol misimplementation, but the latter do happen and are just as bad.
Comments
I'm not sure that you're actually disputing my statement at all.
Your main case there is software developers failing to do protocol design, which is exactly what I'm saying is a bad idea if they don't happen to be independently expert in it.
The reality is these situations would be a whole lot easier to resolve if people actually respected the expertise of each other. This works in all directions, but recent bugs show a definite weakness in terms of respect given towards relatively basic software engineering practices.
I may have been unclear: I am claiming that you cannot be a good protocol designer without sufficient expertise in cryptography AND you cannot be a good implementer without sufficient expertise in protocol design (I have updated my OP to add an instance of an implementation bug caused by insufficient knowledge about protocol design as well: TLS timing attack).
You could make the argument that if the implementer has to know anything about why the protocol or crypto works then the spec is poorly specified.
Certainly it helps to have a minimum of appreciation of the other parts of the domain, but I think you greatly overestimate how important that is for the kinds of problem we've been seeing lately.
In any other field, I would agree with that assessment. In the world of crypto, with side-channel attacks on the sound of your keyboard as you type, I think that having domain knowledge is essential for any implementer.
You could make that argument, but I will join with mehrdada in disagreeing with it.
It's possible that more vulnerabilities are caused by programming errors than by protocol misimplementation, but the latter do happen and are just as bad.