IETF 88 is going to be a pretty hot meeting, what with the world learning about lots of ugly attacks against everyone’s privacy and security. At the end of the day this is a policy problem not a technology problem; but to the extent that anything can be done at the technology level, a lot of the people who can do it are here. So I think these discussions matter, and I’m going to do some rare semi-live-blogging to relay interesting news as it develops.
I’m starting with a report from something called the “Apps Area Working Group”. Monday’s meeting took a very useful, methodical walk-through of the state of the security/encryption art in each of the major application Internet protocols.
XMPP · It was born last millennium with almost no security; after successive updates through RFC6120, now it’s pretty good in theory. Probably 90% of client-to-server traffic is now TLS. Server/backend status isn’t that well understood. Check out IM Observatory to find out how secure your XMPP environment is.
Future plans: Open “manifesto”. Will try to switch public network to all-encrypted-all-the-time May 19, 2014. This could break G+ Hangout/XMPP bridging.
Also working on avenues including DANE/DNSSEC, POSH, key pinning, cert transparency and so on.
Trying to force TLS 1.2 everywhere, >= 128 bits, preferred are forward secrecy and >=256 bits.
StPeter: “The XMPP network has been running since 1999, We need to do the right thing, and if we don’t get it going, we should go home.”
Certificates in Email · Sending: Can use STARTTLS today between Client & Server MTAs on transmission. It is possible, though rare, for either clients or servers to present certs. Some servers use client certs as ID credentials.
Examples: Google & Yahoo always use STARTTLS and encrypt if possible.
Receiving: If you’re picking up with POP or IMAP, clients can and usually do STARTTLS. Neither client nor server certs are commonly checked, if check fails the error message is bizarre and unhelpful and people just click OK.
In messages, e.g. S/MIME: Wide client support, but key management is lame. Watch out for key rollover, it’s easy to make last year’s archived messages with certs unreadable.
Email via TLS · RFC 2595, 3501, 3207, 5804, seem to cover ground pretty well. Cipher suite recommendations are sort of old, absent for SMTP and ManageSieve.
In the real world, major IMAP servers seem to support pretty good & modern cipher suites.
IETF can help with housekeeping, document suites and ports and so on. Also beef up recommendations on requiring mandatory/opportunistic TLS.
Need more work on TLS server identity verification based on RFC6125.
All email encrypted? · [See draft-moore-email-tls]. How to get there... new email accounts should be TLS-encrypted by default, and find a way to upgrade existing accounts, without causing people’s email to stop working.
Can be approached at submission/delivery, relaying, and end-to-end via S/MIME. All this puts a much greater burden on servers and operators.
It’s feasible for mail client to always require TLS connection to servers.
Also, need to require operators to be smart about DNSSEC, cert requirements, and you have to monitor your servers. Implicit TLS beats STARTTLS.
Use of MUST makes conformance to the draft a pretty strong statement.
Opportunistic TLS isn’t good enough because user needs assurance of privacy.
SIP Security · The specs support it, but in practice there is very poor adoption of security mechanisms. Negligible in the marketplace, because SIP users mimic traditional telco architectures which assume VPN or some other network layer does security.
Sticky point is the connective tissue between signaling and media; can bind SIP-layer identities to media streams? How to do key management?
HTTP and TLS · “Optional and at the pleasure of the server”. Server authent mandatory, but client authent rarely used
Looking at TLS for
http:// URIs via opportunistic
Lots of people use interception proxies out there to provide “helpful services”, and TLS generally breaks them, and this is a source of friction.
CAs have become a big problem source. Current trust model simplistic.
HTTP + TLS allows only one origin per connection, which may cripple HTTP/2.0.
Also, too hard to deploy.
How to move forward? · Gather an applications-of-TLS group together and start moving along on multiple fronts.
Need to get all the Email stuff together in one WG.
Some discussion about whether this can be approached in a centralized way. The smart (IMHO) people seem mostly to be in favor of that approach.