Chapter 7 — Networks and protocols

Chapter 7 — Networks and protocols

Lesson map

Lesson 07 published. Map, example, EX019.

flowchart TD
  N0["Learning outcomes"]
  N1["7.1 How email travels"]
  N2["7.2 Authentication checks"]
  N3["7.3 Protocols and judgement"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX019"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["7.1 How email travels"]
  N2["7.2 Authentication checks"]
  N3["7.3 Protocols and judgement"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX019"]

[Learning outcomes]
    |
    v
[7.1 How email travels]
    |
    v
[7.2 Authentication checks]
    |
    v
[7.3 Protocols and judgement]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX019]

Learning outcomes

You will (1) explain how email travels and how sender identity can be forged; (2) describe email authentication at a high level; (3) relate protocol limits to human judgement.

7.1 How email travels

When someone sends an email, their mail server passes it across the internet to the recipient's server, which stores it until the recipient reads it. The basic email protocol was designed for cooperation, not security, so the sender address shown to the reader can be set to almost anything. Nadia learns that this is why staff at Ashcombe received messages appearing to come from the head librarian that were actually sent from elsewhere. Understanding this design history explains why people cannot rely on the displayed sender name.

7.2 Authentication checks

Email systems now add checks that let receiving servers test whether a message came from a server authorised by the sender's domain. When checks fail, the receiving system can reject the message or mark it. Nadia learns these mechanisms in outline only, enough to understand that they reduce forged domain messages but cannot stop lookalike domains or compromised genuine accounts. She notes that technical checks shift the problem rather than removing it, leaving some judgement to people for messages that pass every check yet are still deceptive.

7.3 Protocols and judgement

Whitten and Tygar (1999) showed that even well-designed security software can be too hard for ordinary users, in their study of email encryption. Nadia draws a lesson: when protocols leave decisions to people, the interface must make the right decision easy. She suggests that Ashcombe's email system show a clear tag on external messages and a warning when a display name matches a staff member but the address is external. These cues support judgement without asking staff to understand the protocols underneath.

Worked example

Nadia explains forged sender addresses, outlines authentication checks and suggests external tags and name-match warnings.

Synthetic case. Examples are synthetic; Whitten and Tygar (1999) is real.

Errors and limits

Tags become ignored if everything is external. Checks depend on correct configuration.

Exercises

• EX019 — Forged sender. Why can the displayed sender be forged? Rubric: 3 = basic email was designed for cooperation not security;; 2 = design;; 1 = vague;; 0 = none.
• EX020 — Check limits. What can authentication checks not stop? Rubric: 3 = lookalike domains and compromised accounts;; 2 = lookalikes;; 1 = vague;; 0 = none.
• EX021 — Whitten and Tygar. What did Whitten and Tygar (1999) show? Rubric: 3 = security software can be too hard for ordinary users;; 2 = usability;; 1 = vague;; 0 = none.

Synthesis

Protocol limits leave judgement to people, so interfaces must support it.

Continue studying — chapter 07 of 40

← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →