Eric Rescorla, a TLS expert and co-author of its RFCs, writes about internet security, privacy, memory management, and protocols.
Commenters cite the author as a leading TLS authority and a privacy advocate, and link his posts on DNSSEC/DANE and Apple's CSAM scanning.
> DNSSEC can be trivially used with DANE to protect the entire session. The browser vendors quite consciously decided to NOT do that.
100%. The reasons why are explained in some detail here: https://educatedguesswork.org/posts/dns-security-dane/. The TL;DR is that by the time DANE was created the WebPKI already existed and was universal and so adding DANE didn't buy you anything because you still were going to have to have a WebPKI certificate more or less in perpetuity.
> This is the outcome of browser vendors not caring at all about privacy and security.
This is false. The browser vendors care a great deal about privacy and security. Source: it was my job at Mozilla to care about this, amongst other things. It may be the case that they have different priorities than you.
> You're saying that to provide service for anything over the Web, you have to publish all your DNS names in a globally distributed immutable log that will be preserved for all eternity?
Well, back when people were taking DNSSEC and DANE more seriously, there was a lot of talk of doing DNSSEC Transparency.
> And that you can't even have a purely static website anymore because you need to update the TLS cert every 7 days? This is just some crazy talk!
This is hyperbole, because nobody is forcing you to update the TLS cert every 7 days. It's true that the lifetimes are going to go down to 45 days eventually and LE offers 6 day certificates, but those are both optional and non-default.
Moreover, the…
One of the working group members did an in depth look at the proposal that I thought was fairly even-handed: http://www.educatedguesswork.org/2012/08/initial_notes_on_microsofts_cu.html
> WebRTC itself is so young that a complete rewrite shouldn't be out of consideration if needed. Nobody wants to carry bad decisions over the years anymore.
That's partly true, but also one of the traps of discussing these things outside of the working groups in which they originate. You get new eyes on proposals, from people not caught up in the baggage of past discussions and maybe not as tired of discussing this topic ad nauseam so aren't as ready to settle for the first thing that comes along, but you also lose all the context of ongoing discussions and proposals.
And, of course, you can always rewrite to try to get the perfect spec, but at some point the rest of the world has settled on the thing that was only meant to be a temporary solution, and it's now so entrenched that it's not going anywhere. The real danger looming over any standards body is the perfect (or as he really said, le mieux -- just "the better") as the enemy of the good enough.
I think the idea is that (given the ability to generate SHA-1 collisions) the same technique used to generate MD5 collisions in Postscript files could also be used to generate SHA-1 collisions in firmware files:
http://www.educatedguesswork.org/movabletype/archives/2005/06/md5_collisions.html
Basically, you generate two colliding blobs of random data, and then append identical code to each of them. The resulting concatenations also collide. The code is designed to behave differently depending on which blob precedes it.
That alone isn't very useful. It would be obvious to anyone who reviewed the code that something is going on, and the whole point of the attack is to fool code reviewers. But if you're clever you could obfuscate this in a number of ways. For example, if you can generate a large number of collisions, you could find a pair of blobs such that a given substring, when interpreted as data or code, produces correct behavior for one version and insecure behavior for the other.
BitTorrent has never used MD5.
RSA Security as early as 1996 was recommending against MD5 in situations where collision-resistance was important, because research had started to show weaknesses in its family of hashes. [1]
BitTorrent does use SHA1 (last I checked -- it's been a while). Recently, SHA1 has been shown to have problems, indicating that its collision-resistance isn't as strong as its design target, and might yield to demonstrated collisions soon. [2]
So BitTorrent may want to plan for a transition to new hashes sometime in the next couple of years. Possibilities for a next-few-decades hash could include SHA256/SHA384/SHA512, Whirlpool, or the to-be-determined winner of the upcoming NIST hash competition (like the one that chose AES). [3]
[1] ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf
[2] http://www.educatedguesswork.org/movabletype/archives/2007/08/sha1_rumors.html
[3] http://csrc.nist.gov/groups/ST/hash/index.html
It's not happening, for multiple reasons.
https://educatedguesswork.org/posts/dns-security-dane/
Reasons not to DNSSEC? The biggest one is that it exposes you to misconfigurations that happen routinely even at large sites (because DNSSEC is hard to manage), for no actual security benefit. The "no actual benefit" part is my big reason, though. DNSSEC is pure path-dependence; people do it because they think they should be doing it, because a bunch of people put a standard together back in the 1990s and have been lobbying for it ever since.
If you proposed DNSSEC today, rather than in 1994, it would go nowhere. But since it's been an IETF effort for 2 decades, it now has a life of its own.
Here's a summary of how their proposed system was supposed to work: https://educatedguesswork.org/posts/apple-csam-intro/ (if you want to skim it, search for mentions of "manual review" and "visual derivative")
I suspect the key would be that there'd be a team verifying that something is actually child pornography, because the system is a perceptual hash rather than a strict comparing-bytes so before someone looks at it they're not certain.