Signing Email Phill Hallam-Baker. 2 What are the end goals? Phishing –Organized crime sends email...
-
date post
19-Dec-2015 -
Category
Documents
-
view
225 -
download
0
Transcript of Signing Email Phill Hallam-Baker. 2 What are the end goals? Phishing –Organized crime sends email...
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 [email protected] 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