As you have probably guessed, the authentication user experience should be based on Secure Internet Letterhead.

To apply Secure Internet Letterhead to e-mail, we must define our area of “Secure Chrome.” The natural place for this is in the area where information from the message headers such as the Subject, Date, From, and To addresses is displayed (see Figure 13-1).

Figure 13-1. E-mail message with signature logo

As we saw in the discussion of SSL, the entire user experience must be considered, not just the success cases. Most S/MIME clients provide a satisfactory user experience when an e-mail has a valid, trusted signature, but the response to error conditions is poor to dreadful without exception.

For example, most S/MIME clients warn the user if the message is signed with a certificate that is no longer valid because it expired even if the certificate was valid when the message was sent. Unnecessary warnings are also given when the certificate is not trusted or the message is signed using a signature algorithm that is not supported.

None of these warnings serve a useful purpose when 99 percent of the messages that the user receives are unsigned. The signer cannot anticipate when the recipient will read the message, and he has a limited ability to anticipate which certificate issuers and signature algorithms he might trust.

Adding security to a communication should never degrade the user experience for either sender or receiver. If a message is received that carries a signature that is unsatisfactory for any reason, that message should be treated as if it were unsigned.

Although the principal focus of this book is Internet crime, the principles of design for deployment require us to consider how to establish an early adopter market that can find value in Secure Internet Letterhead before a critical mass of senders and receivers is established.

If a sufficiently large Web-mail provider such as Yahoo!, Hotmail, AOL, or Google were to present Letterhead, a critical mass might be established at a stroke. This is certainly the best chance for rapid deployment, but the critical dependency on a small circle means that we need a backup plan.

The principal purchasers of Internet security products and services are enterprises. If we can find a way that enterprises benefit from Letterhead deployment before a network effect has been established, we have a second early adopter market.

As it turns out, there are two important benefits that should more than repay the (modest) cost of deployment.

The first benefit is that Letterhead provides a means of defeating a form of social engineering known as pretexting. In 2004, a prankster provided a humorous example of pretexting by registering the domain starbucks-inc.com and then impersonating the Starbucks CEO in an increasingly bizarre e-mail exchange with a recent hire.^[1]

The same technique could have been used to obtain information that might affect the stock price, reveal corporate strategy to a rival, or divulge confidential client details. How common is this attack? I don’t know, but I would certainly like a reliable means of measurement.

Displaying the company brand on every internal e-mail provides employees with an immediate means of determining whether an e-mail is from inside the company or outside.

The company I work for has 5,000 employees, five or six principal offices in the U.S., and maybe a hundred worldwide. I am actively engaged in many aspects of the company business, so on any given day, any of those employees might send me an e-mail. There is no way for me to know if someone is an employee or not without checking the organization chart each time. It should be the responsibility of the machine to give me this necessary information.

Letterhead is an authentication technology, so we might expect authentication to be a benefit. A second potential benefit is that Letterhead might discourage undesirable behavior.

Anyone who has managed an e-mail system in a large organization knows about the problem of “e-mails too stupid to write.” Just what is it that causes people to use the company e-mail system to send insults, gossip, pornography, and intimate conversations? Supplies of stupidity are inexhaustible, but anything that makes people more likely to think before they click quickly pays for itself.

A good way to make people think is to remind them that every e-mail message they send is going out on company Letterhead. It is not unknown for an unfortunate letter to be sent out in the post, but I have never seen a message on official Letterhead remotely like the one I received from a U.S. Coastguard address after an (anonymous) experiment to determine whether it was feasible for Blöfeld to use Craigslist to recruit people to hollow out his volcano (see Figure 13-2).

Figure 13-2. A (redacted) message from the U.S. Coastguard

Even though the need for authenticity must be our first concern, the need for confidentiality remains underserved. People who use e-mail for business need to be very concerned about confidentiality, especially when they are responsible for protecting customer’s confidences. Doctors, lawyers, and engineers consider this to be a professional duty.

More importantly for our purposes, confidentiality is a need that is recognized by the enterprises we want to engage as early adopters for Letterhead. We cannot persuade them to deploy a new authenticity solution unless their confidentiality needs are also met.

As a minimum, Alice must be able to send e-mail to Bob confident in the knowledge that Mallet cannot intercept and read the contents. In some situations, we would like to go further, so that Alice can send a message to Bob in such a way that Alice maintains control over the contents so that Bob cannot forward the message to Careless Carol.

The much bigger problem we face is usability. Using the current generation of e-mail encryption standards requires the user to think before sending each message and expects him to notice when encrypted messages are received. That is too much effort.

No damage is caused if an e-mail that does not require confidentiality is sent encrypted. If an e-mail recipient is capable of receiving encrypted e-mails, all mail sent to that recipient should be encrypted by default.

The user does not need to know whether the e-mails he receives were sent encrypted. If the message was sent without encryption, the damage has already occurred and cannot be corrected.

The only time that user input is required is to identify cases where confidentiality is necessary.

Figure 13-3 shows an example of a user interface following these guidelines. The Compose Email dialog has options to allow the message priority (high, medium, low) set and mark the message confidential. Both options are presented in the context of the standard composition dialog and not as a separate pop-up screen.

Figure 13-3. E-mail sending security interface

The user is only ever warned about security if it is not possible to provide the specified or necessary level of security (see Figure 13-4).

Figure 13-4. Warning the user that a message cannot be encrypted

We could spend a great deal of time considering what an acceptable user experience for confidential e-mail would look like, but more than likely we would get it wrong. When we use the term “acceptable,” we are asking, “What is good enough?” If the computer user experience is to improve, we have to stop asking that question and instead ask, “How can we achieve luxury?”

You don’t need to spend hours preparing a luxury car for a road trip; you just put the key in the ignition and go. If the car needs fuel, oil, or water, it will let you know. The same should be true of a security solution. Unless you are personally responsible for administering the system, you should not need to do anything to configure your e-mail to use encryption.

John Aravosis of Americablog, a blogger who has made something of a habit of annoying certain politicians, recently became somewhat concerned that someone might intercept his e-mail. After some investigation, he triumphantly advised his readers that he had installed an e-mail security program in a mere twenty minutes. Twenty minutes might be acceptable for a high-profile political blogger, but for most of us, it is twenty minutes too long. Six months later, he had only received encrypted e-mail from “about three people.”^[2]

Instead of giving the user instructions on how to configure his e-mail program to send and receive encrypted e-mail, the security provider should give the instructions directly to the computer. People find following instructions difficult; computers do nothing else but follow directions.

While we are at it, let’s end the rest of the e-mail program configuration nonsense: entering the address of the incoming and outgoing e-mail servers. Why should the user be required to know what these are, let alone be required to hunt through his ISP’s Web site to find out this information? All network configuration information, such as the address of incoming and outgoing e-mail servers, public key infrastructure, and so on should be obtained from the network infrastructure automatically.

The only security configuration that needs to be visible to the user is the ability to set a default security level for a given correspondent through the address book interface (see Figure 13-5). In a large company, this could be set by an external administrator. Making the process automatic for the individual or the smaller company is more challenging. It might be an application for the Semantic Web.

Figure 13-5. E-mail address book security interface

Alternatively, we might get to the point where deployment and use of confidential e-mail technology becomes so ubiquitous that its use becomes mandatory among professions and businesses where confidentiality is a concern.

We have acquired a rather long list of requirements that the existing e-mail security standards do not meet:

In addition, we would like any new solution to be 100 percent backward compatible with the existing e-mail infrastructure.

Having decided on an edge approach, why can’t we just apply SSL? If it is designed to support any network protocol and it works well on the Web, why not use it for e-mail?

Using SSL to secure e-mail is a good idea indeed. There is already an IETF standard that is widely supported. Unfortunately, applying SSL to e-mail achieves only some of our security goals and only in some situations.

SSL provides an effective, low-cost answer to some of our security needs, but not all of them. Like SenderID/SPF discussed in Chapter 7, “Stopping Spam,” SSL only establishes a security context between machines that are in direct communication. E-mail is a store and forward protocol. Except in rare cases, the sender’s machine does not communicate directly with the recipient’s.

Users need to be able to send and receive e-mail using machines that only connect to the network intermittently. To meet these demands, a typical e-mail makes at least three hops moving from source to destination. The sender forwards the message to his outgoing mail server, where it is put in a queue waiting for delivery. When its turn comes, the message is sent on to the recipient’s incoming mail server, from which the recipient will collect it at some point (see Figure 13-7).

Figure 13-7. Direct mail transfer

We can only establish a security context for one hop at a time. We cannot establish the security context between the sending edge server and the receiving endpoint that Secure Internet Letterhead requires.

As we saw in Chapter 7, the e-mail system is complex, and a message might take many detours on its travels, including alumni forwarders and mailing lists (see Figure 13-8).

Figure 13-8. Mail forwarders

These detours make securing e-mail much more challenging than securing the Web. In addition to limiting the value we obtain from using SSL, each detour represents an opportunity for the e-mail message to become damaged.

If everyone followed the e-mail architecture as we now understand it, messages should never become damaged in transit. An e-mail message is like a snowman with two parts: a head and a body.^[3] The message goes in the body. The head contains a sequence of headers that carry information about the message. These include who sent it, whom it was sent to, the subject, the date, and information describing the format of the message.

If we were writing a new e-mail specification, it would probably prohibit modifications to the message body. If I send a letter by postal mail, I do not expect the post office to open the letter, reformat it in a different font, and staple an advertisement to the end of it. Many governments that used to engage in practices of that type disappeared rather quickly.

Unfortunately, e-mail dates from the prehistory of the Internet, before the importance of such rules was understood. In those days, the Internet was one network among many, and exchanging mail between networks frequently required substantial changes to the message bodies.

Practically every machine produced today is designed to represent characters using both the ASCII character set, where characters are represented by 8 bit-bytes, and the larger UNICODE character set, which uses 16-bit words. When e-mail was being invented, 7-bit machines were common, and 9-bit machines were not unknown. IBM mainframes used the EBCDIC character encoding.

Translating between the formats used on the different systems required masses of complex, one-of-a kind code, the type of complexity that needed to be managed using edge architecture. Modifying messages was considered to be a core function of a mail server rather than damage.

Digital signatures are designed to detect the smallest possible change in a message. This means that a verified digital signature provides the strongest possible proof that the message has not been modified. It also makes the system brittle; a message that was slightly changed and an outright forgery give the same result.

Both S/MIME and PGP support a range of strategies for dealing with the problem of damage. The most powerful technique is to re-encode the entire message using only characters that are known to survive even the most abusive servers. This technique, base64 encoding, all but eliminates the possibility of damage, but it means that the message can only be read by a recipient with a compatible mail reader.

The need for client support is unavoidable in an end-to-end encryption scheme. It is impossible for the ultimate recipient to decrypt a message unless his client is capable of decryption. The same is not true for authentication. This is the root of why we cannot use PGP or S/MIME to support our authentication needs; it is simply not possible to sign every message sent if this will render it unreadable to an appreciable number of intended recipients.

PGP supports a mode that is somewhat less demanding on the recipient. You might have seen e-mail messages that look something like the following:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Testing.

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

Q29uZ3JhdHVsYXRpb25zLCBpZiB5b3UgYXJlIHJlY
WRpbmcgdGhpcyB5b3UgaGF2ZSB3YXkgdG9vIG11Y2
ggdGltZSBvbiB5b3VyIGhhbmRzLg==
-----END PGP SIGNATURE-----

The end user sees the PGP “armor.” This approach allows a message to be read by anyone, regardless of whether that person has a special mail reader—provided that is, he is not confused by the additional gibberish.

In addition to confusion, the armor can create a false sense of security. Only a tiny proportion of the people who receive PGP signatures have the ability to check them and, of those, we can expect none to actually do so. PGP armor violates a core usability principle: A trust indicator is presented that is not trustworthy.

We need a new message format if we are to apply strong authentication to every e-mail sent.

SenderID/SPF does not provide strong authentication and, like SSL, it only provides authentication to machines that are in direct communication. SenderID/SPF was designed to provide a quick fix for e-mail authentication, a system that had known limitations but could be deployed quickly and provide real value. Although SenderID/SPF provides a real benefit in the fight against spam, it is not designed to solve the problem of phishing, which only began to emerge after the deployment of SenderID/SPF had begun.

S/MIME and PGP provide strong authentication, but both have a significant impact on the end user experience, and both are designed for deployment at the network endpoints rather than the edge. If we try to adapt these solutions for the edge, we need to make significant changes. We lose the benefit of legacy deployment. Worse, it becomes a liability, because the change can result in unexpected behavior by legacy S/MIME clients.

Designing a new message format means that we lose the advantage of the existing infrastructure deployed to support S/MIME at a cost suggested by some to exceed $1 billion.^[4] But even if the figure is accurate, we do not appear to have received value for money. If something is not a conspicuous success after a billion dollars of investment and a decade of effort, it is a sign that it is time to try something new and not a case to throw good money after bad.

In addition to a new message format, we need a new key distribution infrastructure that is lightweight, easy to deploy, and provides a compelling value to an early adopter community at no cost.

Although none of the existing message formats precisely meets our authentication requirements, S/MIME and PGP both meet (most of) our encryption needs.

If this was a purely technical decision, we would simply pick one and move on.

From a political point of view, the problem is harder. S/MIME dominates deployment, but PGP dominates in terms of mindshare among system administrators. If we pick PGP, we lose the existing deployed base of more than a billion e-mail clients with built-in support for S/MIME. If we try to pick S/MIME, we lose the support of PGP supporters that we need to co-opt as advocates. And, regardless of which format we choose, both reflect the state of the art in confidentiality in the early 1990s. Neither provides the data-level security features that we would want in the next generation of confidentiality technology.

The political solution is clear: Support both message formats. PGP Inc. has taken this approach for many years. We need to persuade the S/MIME community to do likewise. The extra code required to support a second message format is not trivial, but it is not an unreasonable burden. Writing code is a lot easier than changing strongly held beliefs. The objective is to get people using strong e-mail security; which message encoding they use should be irrelevant.

Although the PGP and S/MIME message formats are adequate for our needs, their key distribution infrastructures need some work. In particular, the user experience requirements we have identified earlier commit us to supporting a transparent encryption mode in which the client automatically acquires and applies encryption keys. We also need to tweak the key distribution infrastructure to support encryption in an edge architecture to smooth the path for deployment.

Our first concern is to provide a domain-level security infrastructure that we hope matches the success of the domain-level SSL infrastructure, but many security specialists would reject any strategy outright unless it provides at least a transition strategy toward an end-to-end architecture in which individual end users hold their own personal signature and decryption keys.

Figure 13-9 shows an e-mail signed using DKIM. The first 16 lines of the message are the head, then comes a blank line followed by the body (Hi, we lost the game ...).

Figure 13-9. DKIM signed e-mail

There are seven separate headers. Each begins with a keyword (called a tag), followed by a colon, followed by data (called parameters).

Six of the headers contain information that is present in every Internet e-mail message. The From header specifies whom the message is from, the To header whom it is addressed to, and so on.

The only header that is affected by DKIM is the DKIM-Signature header which, as you might expect, contains the digital signature information. This contains nine parameters that follow a tag=value syntax. The signature itself is the last parameter, the one that begins b=bnUoMB...

The rules of the Internet e-mail protocol state that any program that sees a message header that it does not understand MUST ignore it. In Internet standards, the word MUST written in capitals has a very particular meaning. A program that does not meet the stated requirement is not compliant with the standard.

Although such instructions are not always observed, this particular instruction is. Many e-mail processing systems add message headers that are not part of the original e-mail protocol. E-mail applications that do not ignore unknown headers quickly break.

The use of a message header to carry the signature header means that we meet the first and most important of our e-mail authentication criteria: Do no harm. Users of legacy e-mail clients are safe; adding a DKIM signature should not result in a negative user experience for anyone.

The second challenge we face is the problem of dealing with damage as the message takes detours. We do not insist that the message signature survive in every case, but we want as many messages to survive as possible, provided it neither compromises security nor imposes an excessive burden on implementers.

The solution is to sign what is known as a canonical form of the mail message rather than the original message. A canonical form is generally defined as a series of rules, such as, “Ignore all spaces at the end of lines.” The technical challenge is to design a set of rules that produce a canonical form such that it is unaffected by the typical changes that may be inflicted on the message by a mail server while preventing an attacker from using it to change the meaning of a message (see Figure 13-10).

Figure 13-10. Canonical form

Getting the canonical form right is a black art. The base DKIM specification defines two canonical forms: simple and relaxed. The relaxed form is somewhat more tolerant of damage than the simple form.

Fortunately, the problem we face today is much less severe than the one faced in the early 1990s. We no longer need to deal with e-mail gateways serving other networks. (A few networks of this type survive, but most do not require support for e-mail, and those that do can make their own arrangements if they want to verify DKIM signatures on the other side.)

As DKIM is deployed, tolerance for mail forwarders that cause arbitrary damage will decrease.

One form of damage that is not likely to disappear is adding information to the end of a message. The legal departments of many companies insist on adding legal disclaimers to the end of every message sent. This particular case does not cause significant difficulty, because we can sign the message after adding the disclaimer. Disclaimers, advertisements, and other appendages do cause problems when they are added by mailing lists, however.

DKIM allows signers to avoid this problem by specifying the length of the message at the time it was signed. The solution is not ideal, not the least because it means that an attacker can add any information he chooses to the end of the message. Nor will it work if the appendage is added anywhere other than the end of the message. But it works well enough for most cases.

We have applied the signature to the message. How is someone going to check it?

First, the verifier needs to know the signature algorithm used. The parameter a=RSA-SHA256 provides this information. That means that the RSA signature algorithm is used and the digest algorithm is SHA256. If the verifier does not understand either, it will not be able to verify the signature.

To locate the signing key, we look at the parameter q=dns/txt. This tells us that the signing key can be retrieved as a DNS TXT record (see Figure 13-11). The parameters s=brisbane and d=example.org contain the key selector and the signing domain, respectively. To obtain the signature key, we retrieve the DNS TXT record for the node brisbane._domainkey.example.org. The key record might look something like this:

brisbane IN TXT ("v=DKIM1;
  p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
                     "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/
                     DkMoGeLnQg1fWn7/zYt"
                    "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
                    "/RtdC2UzJ1lWT947qR+Rcac2gbto/
                    NMqJ0fzfVjH4OuKhi"
                    "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")

Figure 13-11. Key lookup using DNS

The key record requires only two parameters. The k parameter tells us that the algorithm is RSA; the p parameter gives the value of the public key.

The DNS provides a perfectly adequate method of distributing a small number of public keys. If we try to use the DNS to manage a large number of public keys at each site, we start to run into problems. The DNS is large, complex, and critical. It is designed to serve one purpose: translating Internet names into addresses. It is not well suited for adaptability.

Our use of the DNS is reasonable because it relates to machines and not people. Configuring the DNS is a normal step that every network administrator performs when adding a new machine to a network or changing its function. Adding new users to a system does not normally require changes to the DNS unless they are being issued a personal machine, in which case the configuration is for the machine and not the person.

All we need to add Secure Internet Letterhead to our signature is a parameter to the key record to tell the verifier where he can obtain the certificate containing the authenticated letterhead logos:

   brisbane IN TXT ("v=DKIM1;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
            "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/
            DkMoGeLnQg1fWn7/zYt"
            "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
            "/RtdC2UzJ1lWT947qR+Rcac2gbto/
            NMqJ0fzfVjH4OuKhi"
            tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB;"
            "x509cert=http://certs.example.com/Brisbane;")

Retrieving the certificate and verifying the certificate chain requires rather more work than just reading the key value, but we don’t need to do this every time the signature is verified. We only need to do this at the ultimate destination, where the message is being presented to a human. Spam filters can continue to use the key record value.

We don’t even need to fetch the certificate every time we show a message with Letterhead. We can keep a local copy of the certificate, or just the logos and the expiry date in a cache. Even in the largest deployments, the additional processing required is manageable.

The final piece we need in our puzzle is a mechanism that lets a mail server know to expect messages sent from a particular source to carry a signature.

Again, this is simply another task for the existing DNS system that translates Internet names into Internet addresses. In Chapter 7, the DNS was extended to allow an e-mail sender to write a rule that says, “Expect all e-mail from this domain to come from one of these mail servers.” Now we need to write records such as, “E-mail from this domain might be signed with signature key X” and “Expect all e-mail from this domain to be signed.”

At the time of this writing, we are deep in the design of this particular part of the system.

My contention is that the only mail-sending policy that is actionable and thus useful is one that states that every message sent is signed without exception. I would code this as a DNS TXT record as follows:

_smtp_outbound.example.com. IN TXT "DKIM"

This sending policy states that every outbound e-mail carries a DKIM signature header.

In certain rare cases, we might want to add more than one signature to each message. In this case, the policy might be this:

_smtp_outbound.example.com. IN TXT "DKIM=a DKIM=b"

This sending policy states that outbound e-mail carries two DKIM signature headers. One has a key selector with the suffix .a; the other has the suffix .b.

We can extend the e-mail sending policy to support other formats in the same way. We could use the policy SMIME to state that an S/MIME signature should be expected, PGP for PGP, and so on.

One particularly important piece of information we might want to put in an e-mail sender policy is to warn recipients that our domain is likely to be targeted by phishing gangs and that recipients should be extra vigilant in filtering unsigned messages.

Another piece of important information might be to tell a recipient how he can report unsigned messages and messages with signatures that fail verification. This might allow misconfiguration of our servers to be detected before too many messages have been lost or provide advance warning of a new phishing attack.

We did most of our work when we defined our Mail Sending Policy. To support encryption, we need to define a Mail Receipt Policy to tell the senders what form(s) of encryption we will accept.

First, we need to specify what encryption formats we will accept:

_smtp_inbound.example.com. IN TXT "PGP SMIME XKMS"

This receipt policy states that the PGP and SMIME message formats and the XKMS key location service are supported.

If necessary, additional configuration information may be supplied for each protocol in a separate policy record:

_pgp.example.com   IN TXT "KEYSERVER=pgp.mit.edu"
_smime.example.com IN TXT ("XKMS=xkms.example.com;"
                                 "LDAP=ldap.example.com")

We don’t need to put every piece of information necessary to send encrypted mail to us in the DNS itself, but we do need to state where the information needed can be found.

If we decide we need new message formats to support the content rights management systems discussed in Chapter 16, “Secure Networks,” or other new security applications, all we need to do is to define the appropriate tags.

One of the consequences of this DNS policy-based key discovery scheme is that the sender does not need to know whether the encryption key he is using is a domain level or a user key.

This allows us to avoid the consequences of what has become the dirty secret of “end-to-end” security: Not only is it expensive, but end-to-end does not meet the user’s real security needs.

In an enterprise environment, we want to be able to scan incoming messages to see if they contain spam, viruses, or other objectionable material. If spammers can bypass our filters by sending us encrypted mail, they will quickly learn how to do so, and within a short period of time, nobody will be accepting encrypted mail.

The other major limitation in the end-to-end principle is that the modern e-mail system has as many ends as a cat of nine tails. I regularly read my e-mail on four different machines. In addition, my cell phone is also an e-mail pager. Encryption is useless to me unless I can read incoming messages on whichever machine I happen to be using at the time.

Hop-by-hop encryption is less intellectually attractive than end-to-end security, but it meets the user’s real needs much better.

If a user requires more control over his personal security than his network manager allows, he should get a domain name of his own.