Signing Phill Hallam-Baker

2 What are the end goals?  Phishing –Organized crime sends impersonating well known brands –Require means of authenticating messages to user  Security by default –Users expect 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 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 clients –PGP has a significant advocacy base  End to End Security is Bogus –There is not even a canonical reference  The most widely used security protocol is SSL

4 Specific Complaints  Hard to distinguish secure 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 certificates –Need for interaction with a CA

5 Some 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 Situation  Secure 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 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]  must be readable at edge server for compliance  May supplement the user configuration  Alice has no encryption key, use this one

8Confidentiality  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!)

9Observation  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 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 comes from Very Big Bank'  Add disclaimers  Notice that is secure should be visual

11 Ideal 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 indistinguishable from normal  Receiver with legacy S/MIME support –May signed  Receiver with full revised secure – displayed with distinctive logo that shows authenticity.

12 Signed s  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 Proposal  Setup: Make Support 'Out of the Box'  Transport: Core problem is knowing support level –Does this 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 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 Level  Use SMTP Extension 'SMIME' to say: –This port accepts S/MIME –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 is signed –Describe the signing key  Certificate trust anchor is X  Certificate is Y  Signing key is Z

16 The 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 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 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 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 –Lookup SRV record to see if XKISS server for domain –If so query for crypto to use  What is the signing key for YASEP?  May be end to end OR end to domain

19 Traditional PKI Alice Bob Directory ASN1PKIX ASN1PKIX

20 XKMS PKI Interface Alice Bob Directory ASN1PKIX XKMS ASN1PKIX XML

21 XKMS Generalized Interface Alice Bob Directory ASN1PKIX XKMS ASN1PKIX XML DNS Keys PGP Keys Just Keys

22Conclusions  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