Signing EmailPhill Hallam-Baker

2

What are the end goals?What are the end goals?

Phishing– Organized crime sends email impersonating well

known brands– Require means of authenticating messages to

user

Security by default– Users expect email to be secure– Reality must match expectation

Security for free– Only a minority of users are willing to pay for

security

3

Facing the Brutal FactsFacing the Brutal Facts

Security for Gear Heads Security for Real People– Paranoid design leads to unusable user interfaces– Double ended deployment trap

Neither S/MIME or PGP have succeeded– S/MIME is supported by most email clients– PGP has a significant advocacy base

End to End Security is Bogus– There is not even a canonical reference

The most widely used email security protocol is SSL

4

Specific ComplaintsSpecific Complaints

Hard to distinguish secure email from insecure– Clicking on icons to check security is futile– Trust chains are incomprehensible– Web of Trust is more so

A signed message is frequently presented unacceptably– Messages are frequently damaged in transit– Eudora creates stupid attachment files– MUAs with S/MIME 'support' show scary messages

No way to know if a message should be signed

Cost of S/MIME email certificates– Need for interaction with a CA

5

Some Less Brutal FactsSome Less Brutal Facts

Phishing creates major incentive for improvement

Very Large number of S/MIME clients are deployed– Most of application client user base– Web hosted mail only needs change in one place– Most Servers are S/MIME tolerant– While there are few users, there are important users

One stock exchange uses consumer certs for security

Standards Work– SMTP has an extension mechanism– Logotypes X.509v3 Extension is IETF standard– MARID working group really defines a DNS security

policy– XKMS: XML Key Management Service 2.0 [W3C]

6

The PGP SituationThe PGP Situation

Secure email has been hurt by PGP vs. S/MIME – PGP users are often influencers in sales process– Microsoft signs security bulletins using PGP

What does PGP community really want?– 'Free' PKI– Total Autonomy and Control– Validation

Is Web of Trust a Show Stopper? – NO– Self Signed Certs are equivalent to PGP keys– Web of Trust support is equivalent to cross

certificates– XKMS is designed to address this issue

7

Entity To Entity SecurityEntity To Entity Security

Almost no Internet Security is end-to end– Enterprises manage security at the enterprise level– Firewalls are not going away

Domain to Domain security is valid– But so are End to Domain and Domain to End– Lets avoid mistake of over-reaction

Entity To Entity Security– The Domain sets the security policy

May override the user preference [e.g. a bank] Email must be readable at edge server for

compliance May supplement the user configuration

Alice has no encryption key, use this one

8

ConfidentialityConfidentiality

Do we need confidentiality?

Is existing mail server support for SSL sufficient?– It is certainly desirable since it protects headers

Is Entity to Entity confidentiality required?– If so:

Domain Keys Message format is inadequate Had better fix S/MIME Encryption

Encrypt the subject line & date Domain level encryption for regulated

industries Key distribution mechanism (not LDAP!)

9

ObservationObservation

The weaknesses of S/MIME come from two sources– Inappropriate Doctrines

End to end obsession is bogus Compare IPSEC and SSL VPNs Firewalls provide real security

Bad security is better than no security after all Design failures in SSL, WEP have not been critical

– Partitioned Design Process Neglects user interface considerations Encourages silos

S/MIME group is only allowed to discuss message format

Academic focus on solving theoretical problems Poor documentation

10

Rationalizing RequirementsRationalizing Requirements

Deployability– Deployment of secure mail must be seamless– Should not have negative impact on existing users

Security level should meet need– Most users do not require CA issued certs

Authentication through DNS is sufficient

Enterprises need domain level security– Security policy is managed at the network edge

'This email comes from Very Big Bank' Add disclaimers

Notice that email is secure should be visual

11

Ideal Email InteractionIdeal Email Interaction

Sender– Does NOTHING

The infrastructure should work it out

– MUA may allow sender to force use of legacy S/MIME

Receiver with no S/MIME support– Gets ordinary email indistinguishable from normal

Receiver with legacy S/MIME support– May signed email

Receiver with full revised secure email– Email displayed with distinctive logo that shows

authenticity.

12

Signed EmailsSigned Emails

How to tell end user message is authentic– From Major Brand [Microsoft, E-Bay]

Show logo of brand

– From Non Major Brand Need surrogate brand

E.G VeriSign Site Seal C.F MasterCard, Visa, Amex

– Display of Logo Use logotype embedded in X.509v3 certificate

VeriSign Logotype roots are already created

13

Technical ProposalTechnical Proposal

Setup: Make Support 'Out of the Box'

Transport: Core problem is knowing support level– Does this email recipient understand S/MIME?

If so does the client understand domain signatures?

– Should this received message have a signature?– Is this signature automatic or manual?

Edge servers are responsible for:– Making message acceptable to end user– Securing to highest level the channel will bear

14

Types of SignatureTypes of Signature

Automatic– Added by infrastructure without user

intervention– May be stripped by any part of infrastructure

Make sure it does not confuse legacy client

Manual– Added at direct instigation of user

Domain Level Signatures– This message comes from Microsoft.com– Added at edge server gateway– Automatic

15

Signaling Support LevelSignaling Support Level

Use SMTP Extension 'SMIME' to say:– This port accepts S/MIME email– Signing a message will not negatively impact user– NB does NOT guarantee signature will be seen by

user– Could use similar signaling for other content

formats

Use DNS MARID Extension to say:– All outbound email is signed– Describe the signing key

Certificate trust anchor is X Certificate is Y Signing key is Z

16

The Incoming Edge ServerThe Incoming Edge Server

Advertises SMTP SMIME extension– End user client supports S/MIME message

format– Client does not provide acceptable support but

edge will adapt

How do we know client capability?– Web hosted mail knows– Enterprises usually specify client for employee

use If you use Eudora support is your problem.

– New servers/clients can ask client capability May need to extend POP/ IMAP/ MAPI

17

The role of PKI and CAsThe role of PKI and CAs

CA services provide premium authentication– Linkage to PKI hurt both S/MIME and PGP

Cost of CA infrastructure is significant Web o' Trust infrastructure has huge hidden costs

Universal paranoia is a bogus threat model– Professional attackers hack where the money is

Not Aunt Meg's email folder Aunt Meg has different security needs to US Bank

Better strategy for CAs is to encourage free security– Premium consumer Certs for doctors, lawyers, etc.– Premium domain Certs on SSL model– Premium LogoCerts for banks

18

Using XKMS for Out of the Box CryptoUsing XKMS for Out of the Box Crypto

When installed client sets up crypto– Queries SRV record for domain

Is there an XKMS registration server for this domain?– If so Create key pair

Register with XKRSS using SOAP over SMTP Enables reuse of existing authentication infrastructure

When client sends email– Lookup SRV record to see if XKISS server for domain– If so query for crypto to use

What is the signing key for alice@example.com YASEP?

May be end to end OR end to domain

19

Traditional PKITraditional PKI

AliceAlice BobBob

DirectoryDirectory

ASN1 PKIX ASN1 PKIX

20

XKMS PKI InterfaceXKMS PKI Interface

AliceAlice BobBob

Directory

Directory

ASN1 PKIX

XKMSXKMS

ASN1 PKIX

XML

21

XKMS Generalized InterfaceXKMS Generalized Interface

AliceAlice BobBob

Directory

Directory

ASN1 PKIX

XKMSXKMS

ASN1 PKIX

XML

DNS Keys PGP Keys

Just Keys

22

ConclusionsConclusions

End to End security model is bogus– Domain to Domain, End to Domain, Domain to End

are all legitimate goals.– When a model consistently fails, look for a new

model

S/MIME solves the wrong 90% of the problem– There are many parts of the spec that can be saved– In particular message format is viable

Adding missing 10% is not difficult– Use existing extension hooks in protocols– Lack of policy information is principal challenge– XKMS has already addressed PKI issues