Slashdot Mirror
IETF To Change TLS Implementation In Applications
Trailrunner7 writes "The NSA surveillance scandal has created ripples all across the Internet, and the latest one is a new effort from the IETF to change the way that encryption is used in a variety of critical application protocols, including HTTP and SMTP. The new TLS application working group was formed to help developers and the people who deploy their applications incorporate the encryption protocol correctly. TLS is the successor to SSL and is used to encrypt information in a variety of applications, but is most often encountered by users in their Web browsers. Sites use it to secure their communications with users, and in the wake of the revelations about the ways that the NSA is eavesdropping on email and Web traffic its use has become much more important. The IETF is trying to help ensure that it's deployed properly, reducing the errors that could make surveillance and other attacks easier."
Just, please, this time, try to be more careful about who joins your working groups. And especially what their true intentions are.
Sometimes when someone tries to "simplify deployment" or "offers insight to prevent user confusion", etc., you may want to think twice. History repeats itself, you know.
Does this mean that we'll finally give up on this sick certificate-based trust scheme? It's not like Moxie hadn't proposed his own solutions, even with implementations... why don't we make THESE internet standards? Making encryption stronger is just pointless if you can fake a ceritificate.
Both HTTPS and SMTP use TLS to encrypt but usually have you send the password "in plaintext" within the encrypted channel. That's a grievous mistake. You should never, ever transmit passwords.
http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html
still relevant information. :)
Consider this scenario: You're about to connect to a resource, but the service says you need to authenticate. So, a browser native login box pops up. You enter your credentials and those are hashed with the session nonce to key the symmetric ciphers, the connection then commences since the server already has a shared secret with you. It's not like HTTP Auth doesn't exist, it's just that TLS is ignorant of HTTP. If you have a secret GUID on the system, you can hash the domain name of the server with it to produce a unique user ID for each server. Same goes for a master password: HMAC( MPW, Domain + Salt ) = Session generator. HMAC( gen, nonce ) = session key. There, now you don't have to create a new account everywhere you go. One login for everywhere, and the sites can associate a nickname with the UID code if they want. Change your salt and you change all logins everywhere without having to change your password. Only time public key crypto is needed is when you exchange the UID and generator, for everything else use symmetric encryption with the pre shared secret. The window is small enough that PKI is moot.
Besides all the browsers explicitly trust cert roots in known enemy states, so PKI is moot anyway. FF > Preferences > Advanced > Certificates > View Certificates > Hong Kong Post... They can create a cert for Google.com without Google's permission and if they're a MITM, you get a big green secure bar and everything. No one checks the cert chain every time (shouldn't have to), and even if they did the govs can compel the CAs to generate certs under secret orders, or just infect them with a zero-day and do it themselves. All your retard is belong to IETF.
Oh, hey, while you brilliant bastards are at it, why don't you give us salted hashes in the HTML tags that pull in external resources? This way the encrypted page can specify validation codes for the external cache-able content and we can be sure it's not tampered with. Let's end that whole "mixed content" warning bullshit by making HTTP and TLS minimally aware of each other. <img src="..." hash="SHA2/base64: SUVURiBpcyBhbiBveHltb3Jvbi4K" salt="..."> Wow! How fucking difficult is that! Oh, snap! There must be some kind of alien super intelligence infecting my brain, hide your kids, hide your whitepapers!
Oh, That's Right. TRANSPORT Layer security. Ah, gotcha. Sorry, wouldn't want to make you all look like a bunch of morons by suggesting that the layers are just arbitrary lines you don't let interactions across for no damn reason except to further ensure nothing on the net is fucking secure. You know, not like it didn't take me all of one session thinking about this while taking a shit to figure out how you ruined everything, IETF. Internet Eradication Terrorist Fucks? That's what it means, doesn't it?
Earth: The longest running case study in how not to advance as a space faring race.
Remember, NSA has pushed EC technology as something YOU should use (Suite B), as opposed to what THEY use (suite A).
One of the major problems is that currently no limits to what a CA can sign, and even though there is a urgent need to do major revamp to the protocol, I would like see first that TLS 1.next would at least fill that gap.
Can someone, please, if they can justify why for example Türktrust can sign a certificate for a *.gov and .*mil domain? Or why Spanish CA issued a wildcard *.google.com to someone, please?
Limiting that to happen, should be a minimum short distance goal, implementation shouldn't be delayed many years but possibly starting from beginning 2015.
There are many ways to implement these. Adding OID's to root certificate stating policy TLD's which CA is authorized and then also verified from TLD controlling party DNS query asking RR's for that CA whether policy is current and not revoked. The protocol could be lightweight DNSCurve for example. But like I said, there are many ways doing it. Hardest one to solve would be those where no connection exist to network before offered certificate, such as 802.1x/EAP, without chicken-and-egg problems.
IMHO, now founded new work group should concentrate longer period development, but first things first. The big gaping hole in current implementation should be fixed ASAP.
Two years ago a post (Honest Achmed's Used Cars and Certificates) to apply root CA from Mozilla was funny, but not any more. The there are so many incidents with falsely issued certificates, even root certificates, that they could have admitted root to Achmed and his brother who knows few things about computers and situation wouldn't have been much worse by now.
Who TF is IETF
Exactly! The same people you don't trust to make informed decisions...
This... Further... It is not just that CA's can sign for any site, it is that sites can only ever use one CA. If you want to make CA's accountable (ie. when one has awful security, or is buddies with people you don't trust) then the groups and people, need to be able to un-trust them without large parts of the internet going dark. Also, Different people will trust different CA's. There is no CA that both the Chinese and American governments will trust. If you want to sell to both, you will likely need to use an approved CA for each. Similarly, privacy advocates, likely do not want to be using a CA approved by any government. So a single CA makes no sense because it has to be a trusted third party, and there is no such thing as a third party that every combination of two parties trusts. CA's should be negotiated on connection, just like ciphers. A bank could have a dozen certificates, and other, less well funded groups, might have fewer ones. When a CA gets compromised, people can drop it from their list, and use other certificates. There would be reputation systems to figure out which CA's are reasonable to trust (WoT-like systems...)
subject had a greater than sign.. sigh... subject was meant to read, use more than one...
This work is being done by IETF, the Internet Engineering Task Force, which is an open organization who does most of their work via their mailing list. Anyone can read the daily message archive or join. I was a member for several years and you too are welcome to lurk or join and be active.
The only caveat is please remember this is how Jon Postel, DJB, and others of similar skill get work done. Anything you post goes to the email of many of the internet's primary architects, so please read for a while first to get a feel for how the group works, then contribute in your area of expertise. When posting, you're working with the world's top experts on internet technology, so please keep that in mind.
damn it - fat fingered the informative upvote.
Can someone, please, if they can justify why for example Türktrust can sign a certificate for a *.gov and .*mil domain? Or why Spanish CA issued a wildcard *.google.com to someone, please?
Personally; I would favor requiring Server certificates to be signed by a minimum of 3 CAs; perhaps by using a separate trust document file; "Third party CA a auxillary attestation of certificate trust".
The standard could then be --- at least two of the authorities must reside in different geographical jurisdictions. At least three of the attestations must be from authorities that have no business relationship with each other.
And: The user can specify a number of "points" to assign to each CA on a scale from 1 to 5; with a browser default value of 3 for major CAs such as Verisign.
If the score of the certificate is less than 8, or another value user-configured, then the cert is untrusted.
X.509 already has a name constraints extension. The problem with TLS is not necessarily its features or design, but that often solutions or upgrades become difficult to deploy because the standard for "this works" is "every device on the planet can connect", a standard that is often unreachable when you start thinking about buggy SSL stacks in embedded devices that never get upgraded.
IF you were willing to accept, say, a 10% error rate for old devices connecting to your server, you could do all kinds of upgrades (caveat; I pulled 10% out of thin air), but in practice people are rarely willing to accept such losses in backwards compatibility for new features. TLS is a victim of its own success, in a way.
I was wondering why you mentioned Jon, who died over 15 years ago, but then I realized I cannot think of any equally representative names from recent years either... does that say something about IETF, or more about our capacity to annoint new leadership?
Vint Cerf is active with IETF, or was when I was.
When I was new, I very nearly publicly scolded him for posting off-topic. I composed a scolding email before realizing who I was scolding. When I saw that it was v.cerf@ I decided to let someone else, TB Lee or someone, do the scolding if necessary. That that I'm adverse to telling the emperor he has no clothes, but I was a total newbie, a baby compared to them, so I felt I should let the long-time members uphold their own code etiquette in the way they had established.
It was actually Cerf I was thinking of when I wrote Postel, but I'm sure Postel probably was, or would have been, a member.
IETF was good for me in the same way that LKML is. I have a pretty big ego and working with Cerf and people like that helps keep me right-sized. I'm reminded that I'm neither a big shot nor a newbie, but just another guy with some arbitrary level of ability. I know more than some people and I know less than some people. When I start to think I'm an expert, a look at my inbox reminds me that on any topic there are at least a hundred people more expert than I.
This is quite funny
1. Step1 : Google and facebook and other silicon valley giants start massive scale people monitoring that would shame Big brother itself (aka data-mining in IPO speak)
2. They clamor privacy does not exist to make regulators go away
3. Spooks notice, applaud and proceed to raid the resulting intel trove
4. A lone person with some conscience left denounces spooks to journalists (big users of web trackers to try to scrounge enough money to survive while paper editions sink)
5. Silicon valley giants are enraged by the reminder they're not above states and are scared dead of the mass potential loss of revenue if citizens and foreign states started rejecting their data mining. They discover they care about privacy after all, as long as it does not involve their activities
6. Google pushes frantically a new http revision which is TLS-only to the ietf ('cos Google is nerd-kingdom, tech is solution to all social problems, and anything is better than envisaging the monitoring may have been wrong in the first place)
7. Months of debate on the httpbis workgroup. Not everyone has some data-mining to protect, and a lot of people think CAs and certificate handling in browsers like Chrome sucksgreatly (see httpbis mailing list archives). Besides, the proposal would kill proxies and lots of people rely on them
8. the problem is punted to a new ietf wg, tasked with finding if other protocol communities think tls as it exists sucks too. Hopefully it will help dilute TLS opposition in httpbis?
There's lots of old guys still active (Vixie comes to mind right away, and the rest of the ISC and Berkeley old guards) but you're right there's damn few really young faces.
There's a certain kind of post-selfish idealist that the USA, at least, doesn't really breed any more. You're more likely to see folks like that coming from Mexico, or Finland, or South Africa...