Live data from Hacker News

Snowden Meets the IETF

mnot.net

31–40 of 80 posts

Re: Snowden Meets the IETF

#31
post #26
post #5

Earlier quoted context omitted.

I refuse to believe we cannot have both.

Not sure if you've ever heard of Bruce Schneier, but he is regarded by many as the father of modern cryptography. He also happens to know a thing or two about security, and frequently testifies to the US government such as the Senate on cybersecurity related matters. Here are a few of his thoughts on the matter: https://www.schneier.com/blog/archives/2009/02/balancing_sec... https://www.schneier.com/blog/archives/200…

|he is regarded by many as the father of modern cryptography

No, he both isn't that and isn't regarded as that either.

Re: Snowden Meets the IETF

#32
post #2

It must have been an exciting surprise for attendees. I'm glad Snowden said DNS should be encrypted. From the tweet stream provided by @conflictmedia, that was tied for 1st for most re-tweeted, along with making the Internet for users, not spies. (It should be noted that DNSSEC is not encrypted.) Too bad his appearance wasn't recorded, but HUGE thanks to Niels ten Oever and Rich Salz for tweeting major points!

> I'm glad Snowden said DNS should be encrypted. And yet, when HBO screwed up their dnssec config and Comcast blocked the site, how did users react? By demanding Comcast stop verifying! (Fully encrypted DNS can only fail in even more ways than dnssec.)

Unsurprising, since verification breaks things users want and provides no security in return.

Re: Snowden Meets the IETF

#33
post #2

It must have been an exciting surprise for attendees. I'm glad Snowden said DNS should be encrypted. From the tweet stream provided by @conflictmedia, that was tied for 1st for most re-tweeted, along with making the Internet for users, not spies. (It should be noted that DNSSEC is not encrypted.) Too bad his appearance wasn't recorded, but HUGE thanks to Niels ten Oever and Rich Salz for tweeting major points!

> I'm glad Snowden said DNS should be encrypted. And yet, when HBO screwed up their dnssec config and Comcast blocked the site, how did users react? By demanding Comcast stop verifying! (Fully encrypted DNS can only fail in even more ways than dnssec.)

> (Fully encrypted DNS can only fail in even more ways than dnssec.)

The main reasons DNSSEC fails frequently are:

  * pre-computed signatures, rather than online signing
  * a demented, overly complex protocol
  * signatures that expire rapidly
Maybe tptacek can name some others.

The only DNS encryption people are currently using (DNSCurve/DNSCrypt) does per-packet encryption, with a very simple protocol involving only a single ciphersuite designed by djb, and no signatures. This makes all the difference in the world.

If encryption were so bad then people wouldn't be using TLS, SSH, etc. It's the terrible design of DNSSEC that has poisoned efforts in DNS security.

Re: Snowden Meets the IETF

#34

Earlier quoted context omitted.

This is by law in the UK. A 2014 amendment to the 2003 Communications Act forces ISPs to do this. Blame the government, not the ISPs. edit because HN won't let me post a rebuttal to the reply below: Private corporations can be compelled and coerced by the government in other ways that aren't readily publicized. If you think these companies enjoy wasting resources on porn filter then you're crazy. Wikipedia: "Prime Mi…

Separate reply to your edit. [btw, you can click the timestamp in my comment if you are not presented with a reply link] > If you think these companies enjoy wasting resources on porn filter then you're crazy I don't know who's misleading you but BT offered parental controls, including adult content filtering, long before the 2013 governmental push. All they did was turn it on by default (it was off by default, befor…

> there are better technical ways

Sorry I'm a non-devops programmer ;) bad me. What are the better ways? HTTP 403 and friends? (Praying that you won't say "a .exe to fix the browser's access to porn")

Re: Snowden Meets the IETF

#35
post #3

The more I consider the ramifications of these news reports, the more I realize we need full decentralization and total encryption. We have the tech: Strong encryption, Tor-like relays, and the blockchain. What we need is a way to make services based on these technologies not just as easy to use but easier to use for the average Jane. If the internet as we know it is to survive, we have to crack this nut.

That's necessary, but not sufficient. We need both sane policies and technical measures to ensure that nothing less than those policies is possible. If we only have the technology, policy-makers can and will make life difficult both for the users and makers of these technologies; more draconian regimes will simply never allow those technologies to take root to begin with.

Either that, or they will simply intimidate and even torture people for their private keys.

May sound far-fetched, but it isn't.

Re: Snowden Meets the IETF

#36
post #2

It must have been an exciting surprise for attendees. I'm glad Snowden said DNS should be encrypted. From the tweet stream provided by @conflictmedia, that was tied for 1st for most re-tweeted, along with making the Internet for users, not spies. (It should be noted that DNSSEC is not encrypted.) Too bad his appearance wasn't recorded, but HUGE thanks to Niels ten Oever and Rich Salz for tweeting major points!

This is where I get to plug djbdns and DNSCURVE over DNSSEC. I think DJ has been ahead of the curve (no pun intended) on these things for quite some time. I am currently in the process of migrating from bind9 (and avoiding bind10 like the plague) to djbdns wherever possible. Quirks and lack of updates/extensions not withstanding, it's great so far.

http://dnscurve.org/integration.html

Re: Snowden Meets the IETF

#37
post #33

Earlier quoted context omitted.

> I'm glad Snowden said DNS should be encrypted. And yet, when HBO screwed up their dnssec config and Comcast blocked the site, how did users react? By demanding Comcast stop verifying! (Fully encrypted DNS can only fail in even more ways than dnssec.)

> (Fully encrypted DNS can only fail in even more ways than dnssec.) The main reasons DNSSEC fails frequently are: * pre-computed signatures, rather than online signing * a demented, overly complex protocol * signatures that expire rapidly Maybe tptacek can name some others. The only DNS encryption people are currently using (DNSCurve/DNSCrypt) does per-packet encryption, with a very simple protocol involving only a…

The first of those is actually a very important feature. In an age where many organizations outsource their DNS hosting, it's more important than ever to sign your resource records offline.

It's pretty useless to invent a new scheme that gives Amazon and Cloudflare access to your cryptographic keys, so your favorite three letter agency could just go via them instead.

Only you can sign your data, and no one else. That is a feature we cannot compromise on if we face the sort of adversaries mentioned here.

The rapidly expiring signatures is actually a feature too. It serves to avoid the trainwreck that is TLS certificate revocation. But that is a technical problem that may have other solutions. Feel free to suggest one.

Re: Snowden Meets the IETF

#38
post #8

Earlier quoted context omitted.

Security must, by its very nature, prevent you from doing insecure things. This manifests as an obstacle to users, so they end up choosing the insecure route (writing down passwords etc etc). Decentralised systems tend to lose to centralised ones because there's no money locus for advertising, development or curation. It's not totally doomed; the popularity of Snapchat suggests there is demand for services that don't…

Writing down passwords is not insecure. Better to have a written down strong password than an easy to remember password not written down.

Passwords could easily be both strong and memorable if we got rid of ridiculous anti-secure constraints like "password must be at most length X", "password cannot contain a space", etc.

I've heard somewhere of military organizations having people trained to go in an office and search the places people "hide" their password sticky-notes...

Re: Snowden Meets the IETF

#39
post #3

The more I consider the ramifications of these news reports, the more I realize we need full decentralization and total encryption. We have the tech: Strong encryption, Tor-like relays, and the blockchain. What we need is a way to make services based on these technologies not just as easy to use but easier to use for the average Jane. If the internet as we know it is to survive, we have to crack this nut.

We don't have the tech for two important, related things: user-friendly, trust management tools as effective as in person; key management for various, complex scenarios. These two have so many issues that even technical people screw up. I've certainly seen a lot of good work on these. Yet, we're not there yet and getting there is worth a ton of effort by anyone who will try.

We get that, then we might integrate it with our existing technologies to implement and use it. Need the foundation first, though.

Re: Snowden Meets the IETF

#40
post #24

Earlier quoted context omitted.

This conflates "security" in the sense of requirements and "security" in the sense of technology. Users already have security requirements; security technology ought to be enabling them. For instance, encryption lets me back up files to cloud services that I don't trust. Without the technology of encryption, my security requirement would have me not backing up files at all. I wouldn't just decide "oh, whatever" and b…

>encryption lets me back up files to cloud services that I don't trust Any recommendation on an accessible, audited , client for Windows users? Running some company's random binary, especially when you log in and they can identify you, implies a fair amount of trust. Tarsnap's the best one I know of and it's not really accessible for most users.

Not sure what you mean by "accessible", so I'll go from easiest to least easy:

Truecrypt has been audited, works on Windows, and appears to offer an encrypted file container that you can attach to a Windows drive letter.

What you could do is create the container, let DropBox (or whatever) sync the file containing the container, then perform your file operations within the container.

Depending on your needs, there's also GPG4Win, which comes recommended by the GPG project maintainers. AFAIK, GPG hasn't been subject to an extensive audit, but it is venerable, open source, and developed in the open. (Yeah, so was OpenSSL, I know. ;) )

I don't know that there's a way to make a transparently encrypted container with GPG as there is in TrueCrypt, so I suspect that you'd have to:

* Copy your encrypted files

* Decrypt them

* Edit them

* Reencrypt them

* Copy them to the sync directory.

Sounds like a bit of work to me.

If you were on Linux, you could probably use dm-crypt on a loop device, and just sync the underlying encrypted file, but -again-, I have no idea how much auditing has been done on the underlying code (and this fails your "for Windows users" requirement).

Oh, BTW, I replied to our Erlang thread. If you're interested in taking a second look at Erlang, I link to a few things in the comment that might be interesting to you.

Post reply on HN