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.
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.
Well, I can't really make out what you're proposing here.
As far as I can see, the client side has three secrets to maintain - the GUID, master password and salt. If the GUID is unique to a computer, your accounts only work from a single machine, and if you lose the GUID then you lose access to all your accounts. Correct?
The nonce is a "number used once" - i.e. randomly generated for each session in a cryptographically sound way.... so how do the server and client negotiate the nonce for each session? Does one pick it and encrypt it to send to the other? Do they both participate in picking it? Do they use something like Diffie-Hellman to arrive at the value?
I really don't understand your point about changing the salt equals changing your logins without affecting your password. Do you mean if I wanted to lose access to all my accounts everywhere and begin again, I wouldn't have to change my password?
And... how do you know you're talking to the right server in the first place? I don't see any server authentication at all in your proposal.
That's enough for now. The one thing I've learned from studying protocols is that it's really, really hard to get right. Not because the people creating them are dumb or have malicious intent. It may well be time to start creating a new protocol to replace TLS eventually, using what we now know about trust, authenticated encryption, protecting the handshake and side channel attacks. And possibly using some new techniques in there, like identity-based encryption...
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.