Slashdot Mirror

• RFC 5737: IPv4 Address Blocks Reserved for Documentation - 192.0.2.*, 198.51.100.*, and 203.0.113.*
• RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses - 169.254.*.*
• RFC 1918: Address Allocation for Private Internets - 10.*.*.*, 172.16.*.* thru 172.31.*.*, and 192.168.0.* thru 192.168.255.*

Including numbers greater than 255 just makes it look obviously fake.

Absolutely...there's not nearly enough RFC 6921-compliant applications.

I have been adding various facts to the Wikipedia article on Dual_EC_DRBG. A good deal of the most interesting points have not been reported in mainstream media.

* The ANSI group which standardize Dual_EC_DRBG were aware of the potential for a backdoor.
* Three RSA Security employees were listed as being in that ANSI group, making RSA Security's claim innocence claim shaky, since it is less likely that RSA Security didn't know about the back door when NSA paid them $10 million to use Dual_EC_DRBG as default.
* Two Certicom members of the ANSI group wrote a patent which describes the backdoor in detail, and two ways to prevent it.
* Somehow the ways to prevent the backdoor only make it into the standard as non-default options.
* Somehow the people on the ANSI group forget to publicize the potential for a backdoor. Especially Daniel brown of Certicom (co-author of the patent), who also wrote an attempt at a mathematical security reduction for Dual_EC_DRBG, but somehow forgets to explicitly mention the backdoor. The conclusion in Brown's paper also seems very determined to hype Dual_EC_DRBG, whereas the other papers about Dual_EC_DRBG seem excited to hype the errors they find.
* The potential backdoor only becomes public knowledge in 2007.
* Daniel Brown writes in December 2013 that "I'm not sure if this was obvious." and "All considered, I don't see how the ANSI and NIST standards for Dual_EC_DRBG can be viewed as a subverted standard, per se.".

Certicom is the main inventor and patent-holder for elliptic curve cryptography. The two Certicom employees failing to warn or prevent the backdoor they clearly know was possible doesn't reflect well on Certicom.

(Hi. I'm the one Dan was replying to, from another thread. Proof on request, but /. mangles PGP signatures, amongst many other things.)

No, it'd take a Rho attack of 2^127.8 complexity to break that key. Not happening. Way more likely is that someone simply steals the key from the NSA - a daunting prospect - but not particularly useful if all you wanted to know is that there is a backdoor, not to actually use it. There is, and people have been pointing that out since 2006.

I was... surprised at Dan's response. I did not actually expect a response to noting that the backdoor in Dual_EC_DRBG was, and I'll quote myself here, "a backdoor that couldn't have been more obvious if you'd erected a flashing neon sign and driven a mounted parade with a marching band through it", because I didn't think anybody was in disagreement about that. Apparently I was wrong.

My own reply to him, pointing out that even if you mind your Ps & Qs (in the way that he patented, mind you), Dual_EC_DRBG still sucks: http://www.ietf.org/mail-archive/web/cfrg/current/msg03689.html

I don't have a reply to that yet. In all fairness, it has been the Christmas and New Year period, and it's been kind of a busy one this year, and there's some procedural things to sort out that are probably going to take some time (and input from the crowd here would probably only make things worse, right now). Meanwhile, we have recommendations to make about TLS - in short, use it, but for God's sake, turn off RC4 because it's shit and probably worse than the BEAST attack people tended to use it to avoid - and some new things to roll out with that before the big work on TLS 1.3; with encrypted ClientHellos and pinned certificates to stop random CAs impersonating sites high on the wishlist.

An update, by the way: after re-opening the comments period, having been openly informed of the Snowden disclosures (albeit years after cryptographers warned them), NIST have agreed to remove Dual_EC_DRBG from SP 800-90A. So that's something, at least.

/akr

IETF has a working group called P2PSIP which is basically the same thing as mentioned here except over SIP. Basically it is an extension to SIP called REsource LOcation And Discovery (RELOAD), and it allows people to make and receive telephony/video calls over SIP/RTP over a completely decentralized infrastucture, ie. without the phone company. 911 and other stuff hasnt been worked out yet so I dont see it replacing the incumbent telcos at this time, but at the very least it seems like a nice anonymous and open alternative to Skype. What I find interesting is that the AD for this WG is Gonzalo Camarillo, a research guy for Ericsson. I can't see Ericsson or any of their customers getting too excited about any RFC's coming out of this WG. https://ietf.org/wg/p2psip/charter

This is a big (and, I personally fear, unfixable) problem for the IETF and associated Internet bodies. Of course, router security is only a tiny piece of it. Given that RSA has been revealed as taking money from the NSA to weaken security protocols, who knows how deep the rot goes.

One big fight right now is in over the removal of NSA employed Chair of the Crypto Forum Research Group. There will be more.

If there is not encryption, then it is not a VPN.

You, sir, have no clue what you are talking about.

Just go and read RFC4026.

What they are really selling is a tunneled network service, not a secure Virtual Private Network.

The fact that you use the term "secure" in this context already shows that you are clueless. What do you mean by secure? Security can include any of the following: Availability, Reliability, Confidentiality, Authenticity...

The point being that if every NSA agent and their BEAST can read your SSL stream, they can read your password.

The correct way to do things would be widespread implementation of CRAM-MD5 or better yet, its successor SCRAM. These authentication algorithms do not require the host to hold a plaintext version of your password nor do they require you to send a plaintext version of your password.

...even though HTML2 was coming along at the time anyway.

You read it here first: Google was intending to take over the Web a couple of years before it was even founded.

Or use WebRTC, it's encrypted by default with the other encrypted RTP protocol: SRTP.

There is even a system where you can be sure who you are talking to and be sure there is no man-in-the-middle, with an RFC draft to tie it into oAuth or BrowserID protocols:

http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07

https://air.mozilla.org/intern-presentation-seys/

With BrowserID/Persona your privacy will also be preserved.

Persona is the first implementation by Mozilla of the Mozilla developed protocol.

Just out of curiosity: Given a "black box" implementation of a random number generator, is it possible to test its output sufficiently to gain some faith in its proper randomness?

Yes and No. One can statistically analyze output of the (pseudo) RNG and compare it to pure randomness, like atmospheric noise. However, you can't be sure there is no message in the stream. For example: Strong crypto produces enciphered data that looks exactly like pure randomness. It's one way we test for cryptographic strength. Indeed, BSD will now pipe RNG output through Yarrow (a pRNG based on hash functions) to produce randomness. Considering that knowing the initial state of a PRNG reveals its full exact stream of bits, and that hashes produce the same output for a given input: I'm not satisfied with this result either, unless the input is sufficiently salted with device IO timing and other such quasi-random states as in Linux's /dev/random entropy pool.

Seeing as such a piece of hardware need not (and hopefully would not) have any inputs, only an output, it's hard to imagine how someone might hide (and later trigger) a back-door mechanism that could change its behavior post-testing. (But I'm sure there is some way to do it that I'm not thinking of ;))

Strong crypto needs strong randomness for initialization vectors.

While it's true the Ken Thompson Microcode Hack could exist in silicon (Chips could have full featured back-doors in them) it would be far less obvious and simpler to attack a single point of failure: The (hardware | pseudo) random number generator.

It's possible to build a (pseudo) Random Number Generator that is biased in a way that's not noticeably different from pure atmospheric noise in practice, and even passes all the NIST / Diehard tests for randomness. I built one such high entropy pseudo random number generator using a pool of 517 integers and a mixing system. I had arranged the mixing system such that based on a small sample of randomness (50 or so integers, ~1500 bits) one could deduce a weak signal inherent in the pool which then slowly revealed the entire random number generator state in a cascade effect via an Error correction coding present in the bit-stream.

Looking at the source code for my PRNG one wouldn't realize the thing had a back door in it via the selection of primes, constants, and the XOR, shift, AND, etc. mixing strategy itself. The implementation of error correction code akin to Reed Solomon Codes was hiding in plain sight. I sort of turned the weak signal bits on ear and presented them in the stream in "parallel" instead of "serial". The NIST tests chi-square, etc. against my PRNG proved indistinguishable from true random sources such as atmospheric noise, even with gigabytes of data to analyze thanks to the prime number sequence's weak enciphering of the bias pattern.

To make matters worse, I built the system around constants taken from a run of digits in Pi. When apparently any random values will do as inputs for an equation, a known source of digits like this is meant to put cryptographer's minds at ease in that the values aren't just 'magic numbers', pulled from thin air -- Constant numbers selected with possible nefarious purposes. For examples of such 'un-magic selections', see the initial constant states of nearly any hash function, such as MD5, SHA-1, or SHA-2, etc...

......!

According to RFC1925 - Rule 6(a), it's always possible to add another layer of indirection. So, I put my "careful number selection" to create the backdoor one level higher than the values themselves. I went looking for sources of workable constant values in the supposed accepted places. Of course anyone can supply their own pool sizes and init values to defeat my random attack, but in practice folks will use the default values

Unless somebody is going to re-write IP and get the entire planet to implement it, it's a fool's errand to try to implement an anonymous system on an inherently non-anonymous network.

If you want anonymous, use cash.

nobody is forcing them to do anything. it seems the more rational response is the fix the problem instead of treating the symptom. if someone wants to hack your server, do you think something like removing wifi access will stop them?

They're simply following RFC 1925:

(6) It is easier to move a problem around (for example, by moving
    the problem to a different part of the overall network
    architecture) than it is to solve it.

    (6a) (corollary). It is always possible to add another level of
        indirection.

Each time someone makes the claim misconfiguration of DNS enables amplification they are contributing to the problem by refusing to address the root cause.

DNS is flawed by design. You can still extract perfectly useful amplification factors out of non-recursive servers or servers with DNSSEC enabled. All turning off recursion does is cut out ultra low hanging fruit while leaving the problem unaddressed.

There are several ways to actually solve this problem.

1. Use TCP for DNS

2. Implement DNS cookies

3. Globally apply ingress filtering with sufficient granularity to prevent source address spoofing.

I think #1 coupled with TCP fast open extension is the best of the three options. With fast open the setup delay is mostly gone, TCP support is already widely deployed and fast open extensions to TCP can be deployed later as available to optimize RTT delay. With IPv6, DNSSEC and the shitty state of IP layer fragmentation support TCP is necessary regardless.

#2 in the form of http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03 requires more work to push out to DNS infrastructure yet after a few years I can see it following the same trajectory as SYN cookies.

#3 Ingress filtering... am not an operator I don't pretend to know how viable this is to roll out globally, from what comments I have read it is non-viable. This is the only option that would concurrently address all broken UDP protocols susceptible to amplification from a spoofed source address. The downside is spoofing source address can sometimes be a feature. For example it can be used to enable communication without revealing the speakers source address.

Consider the Universe is a simulation which a god has created and is logged on as Admin. Now consider that there are many such universes, and the god logs out of your universe -- Thus no longer existing for all intents and purposes in your universe. Consider this god then deletes the evidence that they existed from the logs. I have just disproved the argument via logic as described in RFC 1925 - Section 2 Paragraph 6

The Fundamental Truths

(6) It is easier to move a problem around (for example, by moving
    the problem to a different part of the overall network
    architecture) than it is to solve it.

    (6a) (corollary). It is always possible to add another level of
        indirection.

Emphasis mine. I applied another level of indirection to your universe. According to RFC1925-2.6(a) you can then win the next round via application of another layer of indirection: Can god create a systems of simulations that he could not log out of, or in to; etc. ad infinitum. The argument has failed because it did not follow the scientific method AKA Skeptical Protocol.

If you are to be a skeptic (or merely a rational individual) then you must learn to use your most powerful weapon against unreason: The Null Hypothesis.

Simply put: In order for evidence in seeming support of a hypothesis (or point of view) to be considered valid the inverse hypothesis must be sufficiently disproved as well.

Hypothesis: God Exists. Null Hypothesis: God Does Not Exist. Unless you can disprove the null hypothesis, then all evidence and reason in favor of the existence of a god means nothing -- It can be written off as merely confirmation bias.

Note: A null hypothesis is considered to be true by default -- If no evidence is found either way, it is the accepted stance. However, a null hypothesis when separated from its original hypothesis is not accepted as valid on its own. A null hypothesis exists only to disprove a stance -- Considered individually it will have a null hypothesis of its own.

Another term to familiarize yourself with is: Unequivocal Evidence. It means supporting evidence which can not be explained by another theory.
Take speciation for example. There is no unequivocal evidence for speciation being supernatural (intelligent design) because speciation can be better explained via natural selection.

Furthermore, Creationism can not be considered a theory because the null hypothesis (evolution) has far more supporting evidence. That's why scientists make such a big deal about things needing to be disprovable. The null hypothesis must be disproved to prove the original hypothesis is not confirmation bias. Eg: Even if I find an IP log for god.com going back exactly 4 thousand years the evidence is unequivocal; Null-hypothetical Internet trolls are just as likely an explanation...

Citation: http://tools.ietf.org/html/rfc1925

You might like this draft then : http://tools.ietf.org/html/draft-nottingham-http2-encryption-01

this document also proposes a "relaxed" profile of HTTP/2.0 over TLS that does not require strong server authentication, specifically for use with "http://" URIs.

Nice. Here's more info on that for other people who didn't know about it:

https://tools.ietf.org/html/rfc4366 (section 3.1)
http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec

Unless I run my own DNS, which is far easier than running a CA.

Not if you are using DNSSEC, it isn't. You talk about running your own DNS under those conditions as though a self-signed cert doesn't require a CA; it does. There's no such thing as certs without a CA...

DANE (DNS-based Authentication of Named Entities) RFC6698 does NOT require the use of a recognized CA, although it does not disallow it. There are four "usage" types for certificates (excerpts from the RFC follows):

1. Certificate usage 0 is used to specify a CA certificate, or
               the public key of such a certificate, that MUST be found in any of
               the PKIX certification paths for the end entity certificate given
               by the server in TLS.
2. Certificate usage 1 is used to specify an end entity
               certificate, or the public key of such a certificate, that MUST be
               matched with the end entity certificate given by the server in
               TLS.
3. Certificate usage 2 is used to specify a certificate, or the
               public key of such a certificate, that MUST be used as the trust
               anchor when validating the end entity certificate given by the
               server in TLS.
4. Certificate usage 3 is used to specify a certificate, or the
               public key of such a certificate, that MUST match the end entity
               certificate given by the server in TLS.

Both Certificate usage 2 and Certificate usage 3 allow a domain's administrator to issue a certificate without requiring the involvement of a third party CA.

For more information on DANE, refer to either rfc6698 or the the wikipedia article.

You're confusing "CA" with "third party CA." You need a CA to have a certificate. Hint: the "C" in "CA" stands for "Certificate."

I mean, I guess you could just open an editor and type something out that looks like a certificate pair, but it won't be mathematically usable, and it won't work when you try to do a Diffie-Hellman key exchange with it :)

Unless I run my own DNS, which is far easier than running a CA.

Not if you are using DNSSEC, it isn't. You talk about running your own DNS under those conditions as though a self-signed cert doesn't require a CA; it does. There's no such thing as certs without a CA...

DANE (DNS-based Authentication of Named Entities) RFC6698 does NOT require the use of a recognized CA, although it does not disallow it. There are four "usage" types for certificates (excerpts from the RFC follows):

1. Certificate usage 0 is used to specify a CA certificate, or the public key of such a certificate, that MUST be found in any of the PKIX certification paths for the end entity certificate given by the server in TLS.
2. Certificate usage 1 is used to specify an end entity certificate, or the public key of such a certificate, that MUST be matched with the end entity certificate given by the server in TLS.
3. Certificate usage 2 is used to specify a certificate, or the public key of such a certificate, that MUST be used as the trust anchor when validating the end entity certificate given by the server in TLS.
4. Certificate usage 3 is used to specify a certificate, or the public key of such a certificate, that MUST match the end entity certificate given by the server in TLS.

Both Certificate usage 2 and Certificate usage 3 allow a domain's administrator to issue a certificate without requiring the involvement of a third party CA. For more information on DANE, refer to either rfc6698 or the the wikipedia article.

Why is 6698 funny? The author was serious. Now 1149? That's funny.

What are your thoughts on RFC 6698 as a possible solution to the CA problem?

Google Chrome supports certificate pinning so you can't go to a site if the certificate used does not match the known one on the list compiled into the browser, which sort-of solves the wrongly issued certificate problem.
RFC 6844 has a proposed DNS type for verifying the proper certificate was served (requires DNSSEC to make sure the DNS was not tampered with).

looks like this is what i was thikning of http://lwn.net/Articles/542642/ http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01

As a newish developer who knows only the minimum I need to about TCP/IP protocol, I was surprised that this, and a number of common things (apparently games, streaming video) use UDP at all. I thought it was basically just used for ping.

Out of curiosity can anyone point out good books for learning more about how to implement applications that use TCP/IP including udp in ways other than the common ssh/http/ftp connections.

ICMP is used for ping, friend. I recommend the Comer books. Also, I'd also recommend that you read the IP, UDP and TCP specs.

As a newish developer who knows only the minimum I need to about TCP/IP protocol, I was surprised that this, and a number of common things (apparently games, streaming video) use UDP at all. I thought it was basically just used for ping.

Out of curiosity can anyone point out good books for learning more about how to implement applications that use TCP/IP including udp in ways other than the common ssh/http/ftp connections.

ICMP is used for ping, friend. I recommend the Comer books. Also, I'd also recommend that you read the IP, UDP and TCP specs.

As a newish developer who knows only the minimum I need to about TCP/IP protocol, I was surprised that this, and a number of common things (apparently games, streaming video) use UDP at all. I thought it was basically just used for ping.

Out of curiosity can anyone point out good books for learning more about how to implement applications that use TCP/IP including udp in ways other than the common ssh/http/ftp connections.

ICMP is used for ping, friend. I recommend the Comer books. Also, I'd also recommend that you read the IP, UDP and TCP specs.

I'd be inclined to wonder if the issue isn't the cypher itself; but maldesigned websites that won't talk to anything except IE with the expected ActiveX plugin.

Yes, that is the problem. Basically there were at least two companies competing for rolling out the SEED cipher to Korean banks after their government announced that all Korean internet commerce was to use their self-developed crypto algorithm. One (or more) of those companies went the standards route, and negotiated to get the SEED cipher added to the SSL/TLS standards in cooperation with KISA, the Korean standards body. Another company went the ActiveX route, taking advantage of the fact that at the time (around 2002 or so) IE represented at least 98% of the browser market in South Korea. The ActiveX control implemented security at the application level, so didn't need to wait for standards bodies to give approval, and they also offered signing of transactions, which is missing from SSL/TLS implementations in web browsers. So because they were faster to market, and offered additional features, they won out. So now South Korea is stuck with a proprietary implementation that forces them to stay with a browser that the rest of the world is rejecting en-mass. On the positive side, the SEED algorithm did eventually get added to the set of standard TLS algorithms, so a migration path is possible.

No, they should standardize on RFC 3501 (Internet Message Access Protocol—version 4, revision 1) because that is the standard and has been since 2003 (but version 4 was first standardized in 1994). Gmail's version of IMAP is just a bastardized kludge whose job it is to speak RFC3501 well enough not to break other people's work (i.e. the clients' performance). Google accomplishes this by providing an IMAP interface on the client-facing end, and then silently changing shit around (like folders turning into labels) on Google's own backend. On the other hand, they don't do some IMAP stuff like the IMAP4 extension called the IDLE command (http://tools.ietf.org/html/rfc2177) at all, but that's okay, because it's not part of RFC 3501, which is the standard.

It's Google's job to implement the standard that's been around since 1994, not the rest of the world's duty to bend over for Google.

No, they should standardize on RFC 3501 (Internet Message Access Protocol—version 4, revision 1) because that is the standard and has been since 2003 (but version 4 was first standardized in 1994). Gmail's version of IMAP is just a bastardized kludge whose job it is to speak RFC3501 well enough not to break other people's work (i.e. the clients' performance). Google accomplishes this by providing an IMAP interface on the client-facing end, and then silently changing shit around (like folders turning into labels) on Google's own backend. On the other hand, they don't do some IMAP stuff like the IMAP4 extension called the IDLE command (http://tools.ietf.org/html/rfc2177) at all, but that's okay, because it's not part of RFC 3501, which is the standard.

It's Google's job to implement the standard that's been around since 1994, not the rest of the world's duty to bend over for Google.

Google are outgrowing intercontinental fibre-optic cables. Too expensive, and insufficient bandwidth! Instead, they're implementing an extension of RFC1149, with the avian carriers replaced with bulk cargo shipping. A station wagon full of tapes has nothing on this!

No, they have been telling the truth. They store a picture until the recipient opens it. They have to, how else could they send the picture to the recipient?

Gee, maybe they could encrypt it and just fucking send it?

Oh, right. Even something "simple" like PGP is beyond users at large. Shameful.

I wonder if this can be adapted to carrier pigeon-based networks?

Let's get serious here. These guys still operate with tiny pieces of paper hidden on a human messenger. This is slower than TCP-IP over pigeons:
https://tools.ietf.org/html/rfc1149
https://en.wikipedia.org/wiki/IP_over_Avian_Carriers

As far as getting a serious indictment on those people through monitoring their Internet activities, well it isn't really worthed trying unless you can keep the costs of trying quite low.

It's basically like asking Google to set the evil bit when they poll your data. I am mesmerized that the MIT Media Lab would turn out something so obviously incapable of disrupting the current ecosystem.

My cloud plan: servers welded shut and housed in 10000 yurts scattered across Mongolia. Network bandwidth may be a problem at first but I'm having some success in my experiments with ponies carrying micro-SD cards.

Interesting! I would like my prosumer mo-social wireless content delivery strategy to synergize with your thinking-inside-the-box solution, but the interface to my problem space may need realignment to fit the new paradigm. Do you support RFC 1149 - IP over Carrier Pigeon?

In fact something like this exists and may even be supported by your browser, but isn't in wide deployment at the moment. The way it works is that example.com goes out and gets an SSL cert for example.com, signed by some reasonable CA. example.com also configures dnssec for their domain. When you go to https://example.com/ your web browser does a DNS query against _443._tcp.example.com for TLSA records. If it finds any, it validates the cert it gets via TLS against the TLSA record; the TLSA record can specify what certs are valid, or it can specify what certificate authority key (trust anchor) is valid, and there are a few other modes. The basic principle is that you now have two paths for validating the TLS cert: the CA _and_ DNSSEC. If both validate, use the cert. If either fails, don't use it. You can read all about it here.

In addition, TLS provides for certificate revocation, so if someone generates a bogus cert and it is _detected_, the cert can be revoked, or if a key is compromised, the cert for that key can be revoked.

These mechanisms seem more likely to be useful than just requiring certs from two different CAs.

The Internet itself, as well as the term "internet", predate the WWW and have always been US-centric. The "inter" in internet is referring to the interconnection of otherwise local networks (internetworking). It was called the Internet long before it was ever even international.

The WWW is great, and I appreciate the international network that we have now, but your terminology is wrong.

Is this a damnation of Internet Explorer, or a damnation of a weak-ass privacy flag labeled "Do Not Track" that corporations can apparently ignore at will?

Newsflash: this is not a indication that Google is doing things the right way. This means Do Not Track needs to be fixed.

Good idea! While fixing it, please do also address the adherence to the RFC3514: examining my router/firewall logs shows a complete disregard of it.
(Oh... btw... maybe you can do something about that pesky first law of thermodynamics? Or, by chance, the second? I mean... if you manage to push a new law criminalizing the use of any of them, we may solve the world's energy related problems)

Joke aside, my point is: if someone wants to track you, how are you going to stop that one?
Making the tracking illegal is not going to solve it, as it doesn't solve the non-adherence to RFC3514; the attempt will be as useless as to repeal a law of physics by a parliament issued law or decree

FreeBSD hosts interesting work with respect to TCP congestion control. An earlier version (I think FreeBSD 8.0) introduced modular congestion control algorithms, and this version introduces CAIA Delay-Gradient (CDG) congestion control algorithm. The check in is here: http://svnweb.freebsd.org/base?view=revision&revision=252504, and an interesting (if slightly esoteric) slide deck is here: http://www.ietf.org/proceedings/84/slides/slides-84-iccrg-2.pdf.

"Lets face it, security and privacy were not designed into the protocols we use on the internet today, they were bolted on afterward, and the government played a big (and self serving) part of that effort."

For those that doubt that statement, please read the documentation provided by the none other than the NSA itself.

http://www.nsa.gov/ia/programs/suiteb_cryptography/

That page was posted by the NSA 4 1/2 years ago and updated in May 2013. Surprisingly, they name names--exactly who worked on what--and even go so far as to provide addresses and personal information for these people. These names can be used to locate networks of "cooperation", just like the NSA uses metadata to find out things about us. For instance, one of the key writers in this document ( http://www.ietf.org/rfc/rfc6318.txt?number=6318 ) when Googled is linked to this document-- https://www.google.com/patents/US6243467 , which in turn adds more names. Follow the names, and see just how much trust you have afterwards.

Dig through the links! Very informative! Start asking yourself what crypto might be safe from the NSA, and you'll quickly realize--the further you dig--that none of it is safe from the NSA. They've identified and created "secure" versions of almost every protocol, for themselves (Suite B), and stuck the rest of the world with lesser versions, versions that would obviously be crackable given that they possess something better.

To be honest, I'm a little surprised that page is still available. I suspect it won't be for long.

The Evil Bit is only defined under IPV4, time to update the specs.

You mean, working hard since 2007?

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

Or did you mean the original http://tools.ietf.org/html/rfc3041 circa 2001?

You mean, working hard since 2007?

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

Or did you mean the original http://tools.ietf.org/html/rfc3041 circa 2001?

... or a sophisticated IPoAC transport mechanism incorporating advanced clandestine protocols like RFC1149 and RFC2549. Obviously the French were hatching a zionist plot to overthrow the elected government before the Egyptians beat them at their own game.

... or a sophisticated IPoAC transport mechanism incorporating advanced clandestine protocols like RFC1149 and RFC2549. Obviously the French were hatching a zionist plot to overthrow the elected government before the Egyptians beat them at their own game.

That's because you lack imagination and keep thinking of TLDs as "Yet Another Dot Com". Just because the ICANN keeps making new alternative ".com" (to make more money?) doesn't mean TLDs have to all be like that.

Google applied for ".here". Not sure what they want it for but more than 10 years ago I proposed that ".here" be a reserved TLD for local use by anyone similar to the way the RFC1918 ip address ranges are used.

http://tools.ietf.org/html/draft-yeoh-tldhere-01

I also wrote to the ICANN to try to get it reserved. I didn't have USD100k to apply for it (in order to give it to the world). In contrast ICANN approved TLDs like .info and .biz.

More complete list here: https://tools.ietf.org/html/draft-hoffine-already-dotless-02#section-2

Looks like they submitted a new one:
http://tools.ietf.org/html/draft-tbray-http-legally-restricted-status-03

Draft has expired.

http://tools.ietf.org/html/draft-tbray-http-legally-restricted-status-02