by

Don Davis

in Proceedings of 2001 Annual Usenix Technical Conference

Question is, why does this keep happening? Is it because wrong people are using the specifications that they aren't supposed to see? Or, is it because the standard makers are not realizing their audience and not making the specifications detailed enough?

Couple other related papers to this topic are,

• The order of encryption and authentication for protecting communications (Or: how secure is SSL?), Hugo Krawczyk, CRYPTO '01
• Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0, Alma Whitten and J. D. Tygar, 9th Usenix Security Symposium, 199

1. Triple Wrapping - SES or ESE seems to be quite secure but can be expensive. Must link outer-layer to inner-layer key pair to make sure signer and encryptor are the same.
2. Good over of several protocols - PGP, PEM, X.509, S/MIME
3. Excellent to understand the attacks
4. Secure programs being developed by application developers instead of cryptographers - application developers, for the most part do not understand cryptography very well and linking cryptographic API to their applications is difficult.

Contributed by Helen Rehn

1. Provides several clear solutions within existing frameworks
2. Tracks historical development of the problem
3. Identifies realistic users of toolkits, frameworks, etc.
4. Pertinent in light of new XML security protocols

1. I thought the paper was way too long for the content.  The main point is that the standards mislead you into thinking that signature and
   encryption are completely modular and independent and the order in which they are used is not important, and this is _not_ true.  The other thing is that standards/specifications are too low-level and people who use them (application developers) don't understand what the semantics/guarantees are.
2. The solution proposed is fairly straightforward too -- signature and encryption need to be linked, either by additional signatures or by
   including sender/recipient info in the encrypted message body. 
3. Going through the various existing standards pointing out how each of them had the same problem made the paper much longer without adding much additional information or clarity.

1. What would be the actual damage by surreptitious forwarding?
2. How about the commercial products in the market today? Does any of them show this flaw?
3. What is easy-enough semantic for application developers to understand and not make a mistake? What if we changed to audience to the end-users?
4. This is problem of abstraction. Certainly the internal details of cryptographic primitives should be abstracted when presented to application developers or end users. But, what is the appropriate level of abstraction? How much can we expect from a normal end user to understand on this topic?
5. Is there any economic incentive for the standard makers or API writers to provide enough details and make the abstractions at the right level?
6. The "padlock" at the bottom of your browser, is it giving people the bad idea? Is it really possible to abstract the whole secure connection semantic to one single icon? If not, how much should a user know?
7. What if we could provide two layers of API, one for the knowledgeable programmer who understands the cryptographic details, and another for those who aren't?
8. In any case, there will be certain gap between the specification and any implementation of it, unless the specification also provides the reference source code.
9. How much of security support should be automated? Is it really desirable to provide a turn-key API to use various types of cryptographic primitives?