I disagree with the premise of your question. I think the overlap is larger than it looks like on the surface. I have come to believe that you cannot do solid secure protocol design without a firm grasp of the basics of encryption schemes. You don't need to be a full fledged cryptographer, but to quote Phil Rogaway, "Reading [Schneier] does not qualify one to do cryptographic design." [1]. In fact, the context in which he wrote "Problems with Proposed IP Cryptography"[1] is a perfect evidence of this: IETF committee designing IPsec, back in 1995, which I think is fair to think of as mostly "professional software developers", was clearly warned about potential consequences of some of their design choices[2] (like using Encrypt-then-MAC), but they reacted quite harshly to his comments and did not take them as seriously as they should have, and actual attacks were demonstrated on those issues years later[3]. For me, reading the mailing list is enough evidence that it is very dangerous to draw the line between secure protocol design and other things. Similarly, I believe the lack of understanding of the reasons behind design choices in a protocol specification will surface as implementation bugs done by purely "secure software development" experts (e.g. "optimization" of random data generation at the beginning of the protocol to use in place of an invalid input by reordering the operations leading to a timing attack in TLS). There is enough historical evidence that makes anything except the "ideal" case dangerous.
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 disagree with the premise of your question. I think the overlap is larger than it looks like on the surface. I have come to believe that you cannot do solid secure protocol design without a firm grasp of the basics of encryption schemes. You don't need to be a full fledged cryptographer, but to quote Phil Rogaway, "Reading [Schneier] does not qualify one to do cryptographic design." [1]. In fact, the context in which he wrote "Problems with Proposed IP Cryptography"[1] is a perfect evidence of this: IETF committee designing IPsec, back in 1995, which I think is fair to think of as mostly "professional software developers", was clearly warned about potential consequences of some of their design choices[2] (like using Encrypt-then-MAC), but they reacted quite harshly to his comments and did not take them as seriously as they should have, and actual attacks were demonstrated on those issues years later[3]. For me, reading the mailing list is enough evidence that it is very dangerous to draw the line between secure protocol design and other things. Similarly, I believe the lack of understanding of the reasons behind design choices in a protocol specification will surface as implementation bugs done by purely "secure software development" experts (e.g. "optimization" of random data generation at the beginning of the protocol to use in place of an invalid input by reordering the operations leading to a timing attack in TLS). There is enough historical evidence that makes anything except the "ideal" case dangerous.
[1]: http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipse...
[2]: http://www.sandelman.ottawa.on.ca/ipsec/1995/04/msg00148.htm...
[3]: http://www.isg.rhul.ac.uk/~kp/CCSIPsecfinal.pdf
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.