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
encryption.
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.
Contributions
Comment feed for ongoing:
From: John Cowan (Nov 04 2013, at 15:00)
So: ubiquitous encryption is now the mark of an "open" network? Solitudinem faciunt, pacem appellant.
[link]
From: Soyuz (Nov 05 2013, at 07:07)
Something needs to be done on 100% false positive rate on HTTPS errors presented to users.
I wish browsers when given non-HSTS HTTPS with self-signed/mismatched domain/expired certificate just presented to users UI *identical* to insecure HTTP UI.
Opera 12 used to do it brilliantly by covering "https?://" part of the URL with "trusted/untrusted" label, so user didn't have to parse the URL and users who expect https:// to always be secure weren't given mixed signals.
Certificate warnings presented to users are totally misguided. Not only they have 100% false positive rate, they also lull users into thinking that absence of warnings means HTTP connection is secure.
sslstrip is an excellent, practical attack on HTTPS and it makes websites look *safer* than HTTPS with false positive warnings.
If browsers never showed scary alerts and only showed positive indicators when connection is secure, then it would be easier to teach users to always look for positive security indicators and question use of HTTP-non-S traffic.
[link]
From: Nathan (Nov 06 2013, at 09:15)
Feels like a bit of wasted effort to me.
If there's one thing that the NSA revelations have taught us, it's that the only secure connection is one where the service provider themselves cannot see your data.
If your service provider is only providing the service in order to mine your data to provide contextual ads, there is no incentive for them to provide that level of security.
I use remarkably unsecure corporate XMPP for chats with my colleagues. My employer have a vested interest in keeping competitors from snooping these data, which they do a reasonable job at, but it is an open secret (which recent lawsuits have made not really even secret) that they can and do snoop the data themselves fairly regularly. But I also use a plugin called OTR (Off The Record) which does end-to-end encryption at the XMPP client level and which prevents snooping and MITM attacks. I feel reasonably secure with that extension enabled (assuming the person I'm chatting with isn't a doofus storing chat logs on company-owned storage).
If I were sending emails I didn't want unfriendly eyes to see, I wouldn't trust TLS-secured email. The NSA wouldn't muck about at the transport level, they'd just step inside Google's datacenter and listen there, once the bits get decrypted. I would use client-to-client encryption, so all Google see are encrypted bits.
It's valuable to implement protocols that keep someone running snort in promiscuous mode from seeing my passwords and cookies. I get that, and I appreciate it. But claiming that protocol-level encryption in any way addresses the interesting problems posed by living in a surveillance state is shortsighted.
[link]
From: Lennie (Nov 10 2013, at 11:45)
I'm missing WebRTC on this list. A new protocol, but always encrypted by default. Don't let the name decieve you it is not Web only.
[link]