This is one person saying another person's claims about DNSSEC are not credible, in part based on benchmarking done in private. One of these people is a cryptography of world renown, the author of the mainstream DNS server with the single best security track record, and the holder of multiple crypto and encoding speed records. The other is a security researcher. Both are speaking in an area of claimed expertise. Their background is extremely relevant to evaluating their claims.
Yes, in order to validate the chain of trust the TLD must be signed but sibling 2LDs have nothing to do with whether a particular 2LD can be signed. If wikipedia.org wants to sign, they can do so, because their parent (.org) is signed, but it doesn't matter whether widgets.org is signed.
Phreebird isn't critical in any way to the arguments he makes, it's simply offered as an example of online signing with DNSSEC. It's right there in the first paragraph, mentioned alongside existing, well-known servers which are purportedly adopting more online-signing-like features.
Which would be only marginally more specific. Humans have been eating "artificial", "synthetic" foods for thousands of years, and all of these things are made from "natural" ingredients because matter can't be conjured from thin air. Can you really come up with a test to distinguish between a just-invented stabilizing agent with unknown long-term effects on health and, say, flour?
You could use a Diffie-Hellman exchange to get a shared secret so things are "obscured by default" but not trusted, then let higher layers deal with trust validation. For example, the TLS certificate handshake could just be a matter of constructing a blob containing the two endpoints' DH public keys and signing it to prove that a man-in-the-middle hasn't intercepted the channel. All the actual encryption would be handled by the IP stack and offloaded to hardware, while the application-layer TLS bits would be used once at startup (and maybe subsequently if the lower layer re-keys) then get out of the way.
Key and cipher negotiation could easily be shoehorned into the three-way-handshake already used to establish connections. AES with a CTR block mode would be the obvious cipher choice since each packet would be handled separately. With TCP you could even just use the sequence number as the counter, although this would be harder at the IP layer.
But yeah, none of this would have been available at the time. Still, given today's technology it would not be difficult to future-proof, especially if the trust machinery is left to the application.
Start with AES-CTR (which wouldn't have been an option in 1979; counter mode hadn't been invented): you can't use TCP sequence numbers as counters; among other things, multiple segments can be sent with the same sequence number, and while the byte described at the stream offset of those sequence number (usually, but not always) agrees with every other packet, no other guarantee exists about the nature of those segments. Reuse of a counter in CTR mode is a devastating flaw.
Running DH over an unsecured connection with no previous trust anchor is also a recipe for disaster; attackers don't even need a fully-functioning man-in-the-middle to break it; they just need to be able to inject two segments, one in each direction, to fixate the derived key.
Everything else you propose to layer on top of this DH + AES-CTR connection is handwaving; if you have to run "application-layer" TLS, what's the value of hardcoding (broken) crypto into the TCP layer?
Sorry for the rabid response to a well-intentioned comment, but wow I couldn't disagree with you more strongly.
I use my own MX rubber-banded together with Postfix, SpamAssassin, and dovecot IMAP. I also have bucket.mydomain pointed to mailinator.com so I can use addresses under that domain as throwaways without the site I'm signing up for knowing about it, although I also use Postfix aliases for long-term throwaways.
My coworker runs his own MX, but bounces all his mail through Google just for the spam filtering.
I'm in the same boat as your coworker. I used to run large-scale mail servers for a living, but these days I just can't bear to deal with the spam problem.
I still have hundreds of aliases I've set up when I needed to give my address to some website (more than can be easily/cheaply set up using Google Apps last I checked) so I still run my own postfix server. It does nothing but forward these days.
Thankfully, gmail's spam filters are apparently smart enough to not overly penalize my IP address even though 95% of what it sends them is forwarded spam.
They're not sitting around a conference table in an underground bunker, stroking their beards and cackling maniacally while trying to screw the open source community as hard as possible. Microsoft is a business. What business sense does it make to release this plugin?
I doubt they pay more for their use of H.264 than they receive from everyone's use of H.264. Providing the codec may cost them money, but it's far from obvious that it's an unprofitable act.
I guess that, for most of the companies on that list, it is a 'pay a bit to prevent legal troubles' scenario, where 'a bit' is a couple of millions. Some of that they will get back when MPEG-LA gets disbanded.
Don't they also have to pay licensing fees to MPEG-LA? What's the overall impact on the bottom line? IMO it would have to be pretty substantial for it to really be a driving factor in the decision-making.
Just thinking out loud, but if this codec becomes dominant, and is only released by Microsoft on the Windows platform, perhaps it's another reason to prefer Windows over OSX?
That is, until it starts taking over the target computers and clicking the links itself. Any naive utility function will produce undesired side effects:
> The author's whole premise is that dropping out is universally bad and should be discouraged, and that staying in school is universally good.
No, the entire premise is in the title: Don't encourage kids to drop out. If they want to do it, they'll do it, and good on them for it. The last paragraph even argues against "extreme points of view" which would suggest that interpreting the article as "they say drop out, don't do it" is totally wrong.
> Where might we be if some of the 'usual celebrity dropouts' hadn't dropped out?
Worthless speculation. We'd be somewhere different, yes, but no less interesting and no worse off.
