Slashdot Mirror

The idea has been floating around for a while. It's still brilliant in the simplicity and anti-censorship attitude of it. What the article doesn't mention is that its an IETF draft now. Wish the error could be something like "451 Bad Government".

I'm not sure if you're being sarcastic, but I searched and found this: http://tools.ietf.org/html/rfc4398 "Storing Certificates in the Domain Name System (DNS)"

GPG supports it! http://www.gushi.org/make-dns-cert/HOWTO.html

It works for emails -- alice.example.org is for alice@example.org.

I bet you didn't click on the ID link describing how to fix it did you?

I did and, first of all, your link describes a proposed standard 5 years ago. I do not see that it has been accepted as a standard to IETF. Second in Eastlake's presentation he notes: "Provides weak authentication of queries and responses. Can be viewed as a weak version of TSIG. No protection against “on-path” attackers, that is, no protection against anyone who can see the plain text queries and responses"

I read that as it probably would work if adopted but it is only slightly more secure than DNS but not my much. Port randomization probably does more.

But yea major re-architecture..blah blah blah..

Well if you need a more thorough explanation you can read this much more detailed and illustrative one.: "As has been alluded to several times, it's the small space — just 16 bits — of the Query ID that makes this attack possible. Though certainly one might wish to increase that ID to something larger (perhaps 32 bits), it's simply not possible do that in the short term because it would break DNS on the internet: the fields are what they are, and they can't be changed casually.

Don't care about popularity contests or who said what.

So you don't care how the hacker who found the problem proposes to fix it. By the way, Kaminsky has never liked DNSSec but he says it's the best solution for now. He actually would prefer DNSCurve but at the time was not ready. It might eventually replace DNSSec. Who do you care about? What about IANA: "DNSSEC is the current answer to this problem. This attack provides clear incentive to deploy a solution like DNSSEC, because without security the DNS will continue to be vulnerable to cache poisoning attacks."

The transport picture and the risk it represents to the larger network is unacceptable regardless of how "secure" DNSSEC is.

In response to this attack all the root servers implemented the solution Kaminksy suggested. People who know far more about Internet security than you and me did this. Either they implemented a popular but less secure solution. Or they don't know as much as you. Or they know what they are doing.

I think technically the flaw cannot be patched, but the vulnerability can be mitigated. reading it, it seems to be an inherent problem with the algorithm.

This is not the case here. It is a flaw in the MS implementation of a technology rather than the technology itself. A flaw by the way does not exist in other versions in Microsofts own products if they are configured properly.

Presumably it is analogous to the DNS cache poisoning flaw that Dan Kaminsky discovered in 2008. DNS was patched to make it less vulnerable but the flaw existed in the protocol itself. There was no truly way to fix it without re-writing the protocol.

There was no way to fix SYN attacks against TCP without replacing it either...oh wait yes there was cookies were added to mitigate the problem and today are widely deployed. The same solution for DNS continues to sit on a shelf and collect dust for no sane reason.

http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03

Replacing it with DNSSec was the recommended course of action.

April 1st must come late this year cuz DNSSec is glued on top of DNS and has all the same insane transport issues that we continue to allow DNS to have. Only now now with significantly higher computational cost and DDOS amplification factors which just might give SNMP with public community strings a run for its money.

Also see: http://tools.ietf.org/html/rfc6090

9. Intellectual Property

      Concerns about intellectual property have slowed the adoption of ECC
      because a number of optimizations and specialized algorithms have
      been patented in recent years.

      All of the normative references for ECDH (as defined in Section 4)
      were published during or before 1989, and those for KT-I were
      published during or before May 1994. All of the normative text for
      these algorithms is based solely on their respective references.

oh yeah, my browser uses UTF-9!

Go ahead, prove me wrong.

Oh shoot, almost forgot.

You are so catastrophically wrong I don't even know where to begin, but I'll give it a shot. Quite simply, MPLS wasn't created specifically to transport L2 traffic. It was a replacement for frame relay. That's basically it. Wide area Layer 2 was just a feature. You seem to think that MPLS was designed to carry Ethernet. It wasn't. That's why we have EoMPLS. It's not native to the protocol, we encapsulate ethernet and transports it over an MPLS core.

From the site, there's not enough info to tell what security properties this proposal has. Mostly, they're just begging for money.

It might not be that hard to do privacy-enhanced mail today. Both browsers and some mail clients (i.e. Thunderbird) accept plug-ins, so doing encryption and decryption on the client side is possible even for web mail. You could still use Gmail, but all Google would see are big strings of random-looking text. Your browser plug-in would decrypt that when displaying Gmail output. Of course, Google's indexing and ad matching wouldn't work.

The big problem is publishing and finding the recipient's public key. The 1993 PEM scheme wanted to do this with SSL-type certs, but that never caught on. Self-signed certs are vulnerable to man-in-the-middle attacks. But suppose that you published your public key on some social network (Twitter, Flickr, Facebook...) and your mail client checked your own key at random times. Then you'd detect if someone was messing with your public key. It's not airtight, but it's better than nothing, and any widespread tampering with public keys would be noticed.

None of this requires any cooperation from, or trust in, mail servers. It's entirely client-side, where it should be.

"Unless you have a written agreement with Google Fiber permitting you do so, you should not host any type of server using your Google Fiber connection"

(Emphasis by me). This sounds more like a "it would be nice if you don't" to me. Heck, even RFC 2119 agrees:

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

I find it telling that Liotta (the author from TFA) is not mentioned in any IEEE RFCs, except in RFC 5345 to say that he makes claims with no real-world measurements. But that's just appealing to authority.

The most troubling part of his proposal, I think, is the elimination of Postel's Law. The Telco-oriented people have been telling the Internet community people all along that what we need is an intelligent network that provides QoS guarantees. The Internet community rejected that, with the result being an Internet that grows in speed and adapts to countless unforeseen applications. Liotta uses the human autonomic nervous system as metaphor, but the fatal flaw is that the human autonomic system has only one brain. The Internet doesn't work with a single controlling entity.

Likewise, his illustration of the Youtube clip is not entirely accurate. Companies like Google and Netflix are making colocation deals with a bunch of the Internet Service Providers, so that most videos don't have to travel through the backbone, Time Warner Cable aside.

There are problems with the current Internet and projects to redo the basis of networking, but Liotta's proposals remind me of those fantasy "cities of the future" fiction that I used to read when I was a kid.

Don't forget the symmetric may change several times in a course of an TLS session. It is called renegotiation. It was made to make things more secure than a single symmetric key but funnily enough, it got exploited...

https://tools.ietf.org/html/rfc5746

http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html

http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION

http://tools.ietf.org/html/rfc5746

Don't forget the symmetric may change several times in a course of an TLS session. It is called renegotiation. It was made to make things more secure than a single symmetric key but funnily enough, it got exploited...

https://tools.ietf.org/html/rfc5746

http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html

http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION

http://tools.ietf.org/html/rfc5746

PGP is not my friend. Its[sic] just RSA

Please read up on how PGP actually works before you continue to rant about it on the internet.

I know, the article is so long. Your takeaway should be that the only things PGP and RSA have in common is that they are both public key cryptosystems and that PGP uses RSA in part of its algorithm. However, RSA is ONLY used to encrypt the shared session key. The actual encryption of the message uses a symmetric-key cryptosystem, typical DES.

In addition to the point about carrier pigeons, even modern technology is re-embracing what others might consider to be obsolete.

See: IPoAC

The blurb says it "redesigns TCP/IP", and the article itself specifically says "congestion control". Which is NOT part of TCP/IP design. Congestion control is a routing feature.

Seriously, it's both incredible how wrong you are with that statement and that somebody rated it as informative. I suggest you read up on the subject: http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm http://en.wikipedia.org/wiki/Congestion_window http://tools.ietf.org/html/rfc5681

That's fair, although I think most of the issues that can be raised which are specific to URIs are either (a) answered by data solutions (databases have no trouble sorting Unicode text) or (b) analogous to existing problems (squatting domains by misusing ligatures is really no different from squatting on typos.) I guess having to write a regex for every gTLD ever would be a pain, but when IDN was first introduced there was an RFC (3490) that specifically set out a turnkey algorithm for ASCIIfying the whole mess. Instead of spooky invisible control codes you only need to deal with cumbersome strings clogged with hyphens.

Oh, because it's too hard to implement a 1997 protocol? (IMAP IDLE)

The irony all these fools running around warning us of dire consequences of having an open DNS servers while concurrently pushing DNSSEC.

In the last two decades the only progress of any kind made to fix these problems is sale of brute force mitigation services to those who can afford it.

Nobody is interested in fixing broken UDP protocols:
http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03

Nor are they interested in applying necessary anti-spoofing filters:
http://en.wikipedia.org/wiki/Ingress_filtering

Mitigation is apparently more profitable than spending money to fix what is broke.

DNT is only marginally less useful than the evil bit. Do they seriously think any advertisement company is going to respect this setting?

What is the problem here? Why couldn't the web browser just make sure that the cookies are passed via RFC3514 ( http://www.ietf.org/rfc/rfc3514.txt ) compliant packets (with the E bit field set to FALSE) if the advertiser is trustable?

The Internet is mostly based on RAND, which may appear to be open source, but isn't. (In some ways I would argue that RAND is better than strict open source; that, to put it mildly, is a matter for debate.)

I actually tried to get a TLD reserved for "RFC1918" style use about 12+ years ago: http://tools.ietf.org/html/draft-yeoh-tldhere-01

I also tried the ICANN but they weren't interested either. And when they approved stuff like .biz, .info. I got the impression they weren't really interested in improving the Internet from a technical aspect but more interested in $$$$. Did the creation of .biz etc really help the Internet that much?

Maybe others may have more success trying it now?

No. .local is for different usage:
http://tools.ietf.org/html/rfc6762
Sure took them a long while to reserve that too.

I proposed reserving a "RFC1918" like TLD about 12+ years ago, but there was not enough interest: http://tools.ietf.org/html/draft-yeoh-tldhere-01

I did try via the ICANN (emailed them to ask them to reserve it). But the ICANN were more interested in "yet another dotcom tld" like .biz .info.
And I didn't have a spare USD100k lying around to apply for the TLD through ICANN, and give it to the world if I even succeeded in getting it.

No. .local is for different usage:
http://tools.ietf.org/html/rfc6762
Sure took them a long while to reserve that too.

I proposed reserving a "RFC1918" like TLD about 12+ years ago, but there was not enough interest: http://tools.ietf.org/html/draft-yeoh-tldhere-01

I did try via the ICANN (emailed them to ask them to reserve it). But the ICANN were more interested in "yet another dotcom tld" like .biz .info.
And I didn't have a spare USD100k lying around to apply for the TLD through ICANN, and give it to the world if I even succeeded in getting it.

.local is used in mDNS (also known as Zeroconf or Bonjour).

.localhost, however, is reserved in RFC 2606.

http://tools.ietf.org/html/rfc2606
You can use .test, .example, .localhost and .invalid.
The use of these TLD's is somewhat defined and not quite similar to the "intranet"-type use you describe, but atleast they're available for private use and nobody will bother you if you use, for example, ".invalid" for your internal domains.

On the other hand, why not simply use subdomains of an actual domainname you own?
If you own example.com, you could use intranet.example.com or perhaps privateserver.internal.example.com

It would be nice if something like ".intranet" could be a reserved TLD.

You shouldn't have several concurrent TCP connections to the same host. Most browsers won't open more than two.

Fast Open is an experimental draft with security flaws and packet duplication problems.
Fast Start hasn't taken off since it was demonstrated 15 years ago.
CRIME also applied to plain old HTTPS. That's been fixed. HTTP 2.0 has different header compression than SPDY that is explicitly designed to counter this attack.
see: http://tools.ietf.org/html/draft-rpeon-httpbis-header-compression-03

The rationale for http-2.0 is available in the http-bis charter. Quoting the spec:...

As part of the HTTP/2.0 work, the following issues are explicitly called out for consideration:

• * A negotiation mechanism that is capable of not only choosing between HTTP/1.x and HTTP/2.x, but also for bindings of HTTP URLs to other transports (for example).
• * Header compression (which may encompass header encoding or tokenisation)
• * Server push (which may encompass pull or other techniques)

It is expected that HTTP/2.0 will:

• * Substantially and measurably improve end-user perceived latency in most cases, over HTTP/1.1 using TCP.
• * Address the "head of line blocking" problem in HTTP.
• * Not require multiple connections to a server to enable parallelism, thus improving its use of TCP, especially regarding congestion control.
• * Retain the semantics of HTTP/1.1, leveraging existing documentation (see above), including (but not limited to) HTTP methods, status codes, URIs, and where appropriate, header fields.
• * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in intermediaries (both 2->1 and 1->2).
• * Clearly identify any new extensibility points and policy for their appropriate use.

Some people think it's a good trade-off, which is why it's included in HTTPS.

Draft 0 was SPDY. It's usually the way that standards evolve from one proposal; cut and shut standards don't often work out.

A fallacy, you say?
https://yourlogicalfallacyis.com/ambiguity

Yes, closed source is obscure, but that doesn't mean it follows the security through obscurity model. Something can be closed source, yet using sound security practices. Example: a closed-source RFC 4880 implementation. Granted, it would be difficult for such an implementation to gain the trust of the security community, but that's a different argument.

How about totally geeking out with paper tape or punch cards?

That would have been my preference too. If the data is un-encrypted, then you can read them with the Mk-1 human eyeball (takes a couple of hours practice, every day for a couple of weeks ; nothing drastic. Russian is harder to learn.) ; even if it's encrypted, you can transliterate from the paper tape to files on your new computer with the Mk-1 eyeball.

A tape reader is "nice to have", but not vital.

Tape has an advantage over punched cards that you only have one way to read it wrongly. But you can manage that risk perfectly adequately with punched card too, so that's not a deal-breaker. (I suspect that card readers have more moving parts than tape readers - all that card unstacking, moving and re-stacking - which would translate to a shorter lifetime.)

Someone suggested using plastic cards or tape ; I'd avoid those options. If your "fire safe" really is a fire safe, then paper should survive just fine while plastic may melt.

But again, the whole idea is fundamentally silly. If you really want the data to be secure, "disaster-recovery grade" backup is not exactly rocket science. Encrypt as desired. If you only want to do it with small amounts of data ("account information," whatever that means) then substitute SD cards, memory sticks or whatever floats your boats, but keep the data regularly refreshed. If you've really got to keep the data secure and usable for decades, then you need to go to "disaster-recovery grade" backup anyway, so just bite the bullet and pay for it. Then pass the cost to your customers. If they don't want to pay, then you probably don't want them as customers. This also applies if they're family.

I suppose it could be someone looking for a plot element in a "steam-punk" genre. That could be quite amusing. There may even be an RFC for that, similar to RFC 1149.

Everyone you wish to interact with has to as well

"The problem with email is that everyone you wish to interact with has to have it as well."

"The problem with putting up a web page is that everyone who views it has to have a web browser".

Too bad there isn't an actual RFC for end to end email encryption, or something, to allow easy interoperability between mail clients in the realm of encryption. Maybe someone should get to work on that .

Everyone you wish to interact with has to as well

"The problem with email is that everyone you wish to interact with has to have it as well."

"The problem with putting up a web page is that everyone who views it has to have a web browser".

Too bad there isn't an actual RFC for end to end email encryption, or something, to allow easy interoperability between mail clients in the realm of encryption. Maybe someone should get to work on that .

Blah, blah, http://www.ietf.org/rfc/rfc1149.txt

There is DNSSEC with DANE.

Create your self signed server certificate and publish it in DNS. Sign it with DNSSEC.
You can't beat free. See http://datatracker.ietf.org/doc/rfc6698/

Agreed. Domain squatting + evading 'due process' on his tax issue + conspiracy of the parties to do (a) & (b) . Even more specific, how come nobody ( even all you spell-checkers) even bothered to cite RFC 1480, the "right way" to name a web domain for a government entity? http://tools.ietf.org/html/rfc1480

Am I missing something that makes this idea different from RFC3161?

Ever since the invention of cryptography capable of 'signature', 'virtual notary' has merely been a matter of finding somebody you'd actually trust to be a notary, and then having them sign stuff. If you give them a clock, you can even have 'trusted' timestamps!

The bigger trick, and something that would actually be worth writing home about, is doing this without trusting somebody who almost certainly doesn't deserve it.

RFC1149 has been deprecated by RFC2549.
RFC1149 has been adapted to IPv6 by RFC6214.

RFC1149 has been deprecated by RFC2549.
RFC1149 has been adapted to IPv6 by RFC6214.

How about proposing an infrastructure upgrade to support RFC 1149? (TL;DR: RFC for Transmission of IP Datagrams on Avian Carriers).

When last Connectify appeared on Slashdot, I stopped reading the moment I saw the word cloud. Now Connectify is back and it's completely different, but is it really?

I'm looking to Alex to clarify my understanding of this, but if I understand correctly, the Connectify "client" must connect to a Connectify server in order for it all to work. So, does the client require multiple internet connections to a Connectify server(mine?) with very high speed internet and or multiple internet connections? If not, doesn't the client's single internet connection to the server not become the bottleneck and if so, what's the point?

Finally, there seems to be harping on the ability to improve streaming performance. How does that work? Even if both client and server have multiple internet connections being bonded/multiplexed channels Netflix, for example, is only going to offer a single connection for the stream's origination, again choking down your connection to a single TCP stream over a single internet connection, which my Connectify server will then needlessly split into a bonded connection.

The only situation where I can see value in this is where my server has a highspeed internet connection and my client is only able to get multiple low speed internet connections which Connectify then multiplexes. Thus the 10Mbps Netflix tream hits my Connectify server and the client receives the stream over 8 xDSL connections. This sounds exactly like Multilink Point-to-Point Protocol(MLPPP) circa 1996.

What am I missing?

If cold fusion were invented tomorrow everything changes...

True. I for one would be worried about getting hit by one of those flying pigs.

With sufficient thrust, pigs fly just fine.

oink, flap ... oink, flap ... oink, flap

If cold fusion were invented tomorrow everything changes...

True. I for one would be worried about getting hit by one of those flying pigs.

With sufficient thrust, pigs fly just fine.

Why would anyone use RFC1149, when it's been essentially superseded by RFC2549? I mean, really!

You are talking about A standard. The OP was talking about THE standard.

I can categorically say in the last 20 years I have not received an email implementing any of S/MIME. S/MIME is only marginly more wide spread than RFC1149

No smpt doesn't support encryption between servers.

Actually it does. But obviously both servers (sender and receiver) must be configurered to use it (which most aren't, unfortunately). And sender must be configured to check receiver's certificate (which even less are).

It's not a protocol issue, but a configuration issue.

And knowing this, it is indeed unwise to include such confidential info in an e-mail.

MPTCP is way better than what Connectify is proposing... It is an open standard too...
http://mptcp.info.ucl.ac.be/
http://datatracker.ietf.org/wg/mptcp/charter/

You know that mDNS /is/ a standard for network discovery, right? http://tools.ietf.org/html/rfc3927

Microsoft is listed in the RFC, but haven't bothered to implement, as they bet on the uPNP horse with WinXP way back when.