Slashdot Mirror

We don't need a law, we just need to have wider adoption of RFC 3514, "The Security Flag in the IPv4 Header".

You can store certificate fingerprints in dns, and if the dns zone is signed with dnssec you can use it as a trust authority and avoid the whole root CA crazyness. See: http://tools.ietf.org/html/rfc6698 I suspect google dosn't support it tho :(

Free, trusted, certificates from https://www.startssl.com/ - no excuse at all for using self signed, at least until DANE/TLSA is deployed.

". When I tried explaining what the link was, that his account had been hacked, and that he should change the password to his @aol.com email account, his response was 'No, I think your account was hacked, since the email came from you."

Your best bet is to stop trying to explain things to him until you understand them yourself. Nobody's account was cracked. Neither your e-mail, nor your Uncle's, has to be cracked for someone to forge an e-mail. Any script kiddie can send an e-mail to anyone else that claims to be from whomever they want. All that is needed is an open SMTP port. RFC 822 See also RFC 822

NTSC television to the bitter end was 29.97.

No. NTSC television is (as there are still LP NTSC transmitters broadcasting), as best as anyone can figure, 29.970026164311878597592883307169 Hz. (And yes, it matters.)

Explanation from this posting:

Horizontal Scanning Frequency (lines/sec) / 525 (lines/frame) where

Horizontal Scanning Frequency = Chrominance Sub-Carrier * 2/455

Now, since Chrominance Sub-Carrier for NTSC is exactly 3,579,545Hz, then doing the arithmetic one ends up with:

( 3,579,545Hz * 2/455 ) lines/sec / 525 lines/frame = 29.970026164311878597592883307169 frames/sec

Note that this is still not quite 29.97002617, which seems to be a result of rounding up at the 10 parts per billion resolution.

So I guess the final conclusion is that the exact frame rate for NTSC turns out NOT to be 30000/1001, but rather to be 7159090/238875, which can be reduced to 1431818/47775.

see http://www.ietf.org/rfc/rfc1149.txt

I work with phones for a living at the largest private employer in Philadelphia.

While office phones are clearly on the decline, they ain't dead yet. We have approximately 20k phones, half of which are VoIP and half of which are either POTS or a digital offering from the local carrier. All of them are converting to VoIP, slowly, and in the process I'm watching the attrition that the OP probably expects. It makes sense to get rid of single lines where they're unused and unnecessary.

However, there remains the complex office setup where you have administrative assistants, or a suite front desk, and shared line appearances. Once someone wants to be able to put a call on hold on one phone and pick it up on a different physical phone, they want it to work like the same technology did in the 80s.

Of course it was easier in the 80s, when those phones shared a dedicated physical copper pair that carried nothing but the voice. With digital signaling it's significantly trickier; Broadsoft has a proprietary protocol to handle this, and the IETF specification (http://tools.ietf.org/html/draft-anil-sipping-bla-04) never left Internet Draft status (which, frankly, is a good thing as it's a very poor protocol).

I don't see that complex setup going away any time soon, as it's a common VIP pattern.

Is that the IETF WebRTC draft mandates the Opus audio codec for all clients..
http://www.opus-codec.org/

From:
http://tools.ietf.org/html/draft-ietf-rtcweb-audio-01
3. Codec Requirements

      To ensure a baseline level of interoperability between WebRTC
      clients, a minimum set of required codecs are specified below. While
      this section specifies the codecs that will be mandated for all
      WebRTC client implementations, it leaves the question of supporting
      additional codecs to the will of the implementer.

      WebRTC clients are REQUIRED to implement the following audio codecs.

      o Opus [RFC6716], with any ptime value up to 120 ms

A Standard for the Transmission of IP Datagrams on Avian Carriers http://www.ietf.org/rfc/rfc1149.txt

Patent # 6,742,087: "Oxidative process for exchange of atmosphere across a membrane."

You all owe me everything you've ever earned.

Well, that depends entirely on the claims. What exactly is the "oxidative process" you've patented, and what part of the process would not be obvious to someone skilled in the art of biochemistry?

This patent thing is getting to the silly point. The original idea was that by making some ideas owned by certain parties, you would force others to innovate around them.

No, the original idea was to create an economic incentive to solve one's own design problems, rather than just waiting for someone else to do the hard work, then copying their result cheaply.

In the grand Slashdot tradition of bad analogies, consider a school where cheating on exams is forbidden, but students are allowed to openly sell their answers for whatever price they want. Now there's a financial motivation for a student to do their own work first, and sell it off. Of course, there are bullies trying to get something for nothing through sheer force, and there are also manipulators who will make false accusations to screw over someone else.

But that doesn't really apply when we're talking about a standard (Wi-Fi) on a standard type of device (PDA).

Okay. Now implement the standard RFC 1149 on a cell phone. When you figure out how to fit the tiny birdcages into the phone, breed the tiny pigeons, and train them to seek a particular mobile device rather than their home, let me know. Since it's just combining two standards, surely it's not a problem if I copy the solution?

At that point, we're just holding ourselves back.

What's holding our technology back isn't the patent system. It's the abuse of combining patents and standards, with different license terms to different manufacturers of "standard" devices. What I'd like to see are reduced patent terms, based on the time-to-market for different industries. Software, for example, may only have a patent life of five years, because after that time the state of the art will have moved on, and the old program is obsolete. I'd also like to see a requirement for any patented standard to have a fixed license fee. If your technology becomes part of a published standard, you must allow licensing at a flat per-copy rate that is open for alteration by a suitable judge.

Because .gov predates the geographical domains like .us.

They were introduced at the same time, in the same RFC...

They were described in the same RFC, but .gov was established at that time and .us was not. Specifically, in RFC 920, the following TLDs domains are identified as established with specific administrators and agents: ARPA (temporary, for existing ARPA-Internet sites pending transition to new TLDs), GOV, EDU, COM, MIL, and ORG.

Additionally, the following categories of domains were described as being available, but having no instances established: countries (identified by the ISO-standard two-letter english country codes—which would include US), and multiorganizations.

The problem is most any terrestrial network protocol expects a minimal signal-response delay between nodes

RFC 1149 does not assume this, though the current implementation would have to be modified to avoid complete packet loss in a non-terrestrial environment - BF Skinner's work suggests one obvious adaptation:

http://tools.ietf.org/html/rfc1149
http://historywired.si.edu/object.cfm?ID=353

The article is correct, the DSN has just a couple of letters in common with DTN, and nothing to do with the Bundle Protocol.

Delay/Disruption-Tolerant-Networks have been researched and developed by the DTN Research Group and the Bundle Protocol has been an RFC since 2007. It's possible to download an open-source reference implementation from SourceForge.

Actually NASA also use their own protocol, called ION (Interplanetary Overlay Network).

Assuming this will not be my day job, that the local populace is rather poor, and that because of the hills, line-of-sight service will be difficult, how could I set myself up as an ISP? I have considered WiFi mesh networking, and even running wires on the power/telephone polls, but the required licensing and other issues are foreign to me. What would you do?"

Dear hawkeye,
Please consider following RFCs relevant for your situation: RFC 1149, RFC 6217, and don't forget RFC 6214 because the Internet is switching over to IPv6.

Assuming this will not be my day job, that the local populace is rather poor, and that because of the hills, line-of-sight service will be difficult, how could I set myself up as an ISP? I have considered WiFi mesh networking, and even running wires on the power/telephone polls, but the required licensing and other issues are foreign to me. What would you do?"

Dear hawkeye,
Please consider following RFCs relevant for your situation: RFC 1149, RFC 6217, and don't forget RFC 6214 because the Internet is switching over to IPv6.

BAHAHAHAH if only I had mod points =)

RFC 1149: http://tools.ietf.org/html/rfc1149

I propose that the Internet be declared a sovereign entity or a federation of sovereign entities (one per nationwide network, perhaps) similar to the way the Holy See is a sovereign entity (headed by the Pope) with whom nations can maintain diplomatic relations. I nominate Vint Cerf for the title of chairman of the Internet Federation (in part due to his RFC 3271.) The Internet Foundation would be responsible for global guidelines that nationwide networks must follow to be considered part of the Internet; nationwide networks would be allowed to come up with other guidelines as long as they don't violate the global guidelines.

Relying on corporations to honor the DNT is like relying on intruders to set the evil bit.

The headline is slighly misleading. It's not MSFT's spec, it's the Trusted Computing Group (TCG) and their TPM spec.

One of the goals of the new TPM spec was to allow a better way to replace some algorithms because the original TPM spec entangle SHA1 hash in such a way (with the PCR extension mechanism) that it was difficult to replace that hash algorithm when weakness was discovered that algorithm and people wanted to replace it. Once you change the design and open that up you should probably include the usual suspects.

Some interesting additional algorithms added to the support library were SM3_256 and SM4 (the hash and symmetric key algorithms mandated for use in chinese DRM), WHIRLPOOL512 (hash function from NESSIE). In addition of the normal RSA public key stuff, they've also added ECC, ECDSA, ECDH, ECDAA, ECSCHNORR (a smattering of ellipitic curve based standards) to the mix in order to help gain acceptance in those markets that want/need shorter key lengths that are available to EC-derived algorithms that presumably have similar security to their RSA counterparts with longer keys.

Interestingly, although they include the SHA2 family of hash functions as an SHA1 upgrade, the newly minted SHA3 was strangely absent. Also, I don't think they have included SM2 (the chinese ECC signature technique), but that's probably just an oversight. I expect both of these omissions to be remedied with the next release.

The headline is slighly misleading. It's not MSFT's spec, it's the Trusted Computing Group (TCG) and their TPM spec.

One of the goals of the new TPM spec was to allow a better way to replace some algorithms because the original TPM spec entangle SHA1 hash in such a way (with the PCR extension mechanism) that it was difficult to replace that hash algorithm when weakness was discovered that algorithm and people wanted to replace it. Once you change the design and open that up you should probably include the usual suspects.

Some interesting additional algorithms added to the support library were SM3_256 and SM4 (the hash and symmetric key algorithms mandated for use in chinese DRM), WHIRLPOOL512 (hash function from NESSIE). In addition of the normal RSA public key stuff, they've also added ECC, ECDSA, ECDH, ECDAA, ECSCHNORR (a smattering of ellipitic curve based standards) to the mix in order to help gain acceptance in those markets that want/need shorter key lengths that are available to EC-derived algorithms that presumably have similar security to their RSA counterparts with longer keys.

Interestingly, although they include the SHA2 family of hash functions as an SHA1 upgrade, the newly minted SHA3 was strangely absent. Also, I don't think they have included SM2 (the chinese ECC signature technique), but that's probably just an oversight. I expect both of these omissions to be remedied with the next release.

AFAIK it's a Twitter-specific code, not specified in the HTTP RFC 2616. The more correct code would be 429, specified in recent RFC 6585, but it's from April 2012.

The general concept of rate limiting would be mentioned in RFCs for a variety of lower level protocols, like the RFC 2463 for IPv6 from year 1998, so I would look for prior art over there.

AFAIK it's a Twitter-specific code, not specified in the HTTP RFC 2616. The more correct code would be 429, specified in recent RFC 6585, but it's from April 2012.

The general concept of rate limiting would be mentioned in RFCs for a variety of lower level protocols, like the RFC 2463 for IPv6 from year 1998, so I would look for prior art over there.

AFAIK it's a Twitter-specific code, not specified in the HTTP RFC 2616. The more correct code would be 429, specified in recent RFC 6585, but it's from April 2012.

The general concept of rate limiting would be mentioned in RFCs for a variety of lower level protocols, like the RFC 2463 for IPv6 from year 1998, so I would look for prior art over there.

The way to handle this at the link layer is to have a way to indicate that a packet should be given a higher level of effort to deliver it correctly (i.e. that if the link layer can't deliver it, the layers above it will be retransmitting it anyway, so go ahead and spend whatever extra resources are appropriate given that hint).

See http://tools.ietf.org/html/rfc2597 and its follow up http://tools.ietf.org/html/rfc3260 for example.

This type of handling is just another type of QoS and needs to be handled at each link, making it end-to-end is inappropriate.

The way to handle this at the link layer is to have a way to indicate that a packet should be given a higher level of effort to deliver it correctly (i.e. that if the link layer can't deliver it, the layers above it will be retransmitting it anyway, so go ahead and spend whatever extra resources are appropriate given that hint).

See http://tools.ietf.org/html/rfc2597 and its follow up http://tools.ietf.org/html/rfc3260 for example.

This type of handling is just another type of QoS and needs to be handled at each link, making it end-to-end is inappropriate.

It is designed to be small and easy to implement. Therefore, it lacks most of the features of a regular FTP. The only thing it can do is read and write files (or mail) from/to a remote server. It cannot list directories, and currently has no provisions for user authentication.

...if you care about coping with packet loss, why are you using a protocol who's main feature is that you don't care if the packet is received or not?

Because TCP isn't designed for the type of loss that it is being relied on to abstract away... so someone created a fix. Such violations of networking abstractions are okay, as specified in RFC 3439

However, in the data networking context structured layering implies that the functions of each layer are carried out completely before the protocol data unit is passed to the next layer. This means that the optimization of each layer has to be done separately. Such ordering constraints are in conflict with efficient implementation of data manipulation functions. One could accuse the layered model (e.g., TCP/IP and ISO OSI) of causing this conflict. In fact, the operations of multiplexing and segmentation both hide vital information that lower layers may need to optimize their performance.

Yes, there is an official IETF RFC encouraging violating standardized network abstractions. Hacks are a feature, not a bug : )

Terry Kramer, the U.S. special envoy to the conference, said the US opposes proposals from some of the 'nondemocratic nations' that include tracking and monitoring content and user information, which 'makes it very easy for nations to monitor traffic.'"

This quote is so rife with arrogance that it makes me vomit, coming from a government that does nothing but blatantly spend money and spy on it's people.

Well, maybe you should read this proposal by China Mobile to split up the internet via "DNS Extension." Aside from the obvious criticisms and assuming we just blindly said "yeah, sure, China, whatever you want" let me ask you this: Will the situation improve for US citizens? Will the situation get worse for Chinese citizens? I think you have to agree that the answers to those questions are no and yes. Whether or not the United States spies on its own citizens is nothing more than an ad hominem attack to ruin this discussion about putting control of the internet into the hands of other nations that do not have laws against spying on its own citizens and, in fact, are places where unannounced and confusing censorship seems to be the norm.

Actually, if you want completely failsafe encryption (excluding actually cracking the key itself) you need two three things:
1. Trusted endpoints (i.e. devices that you can trust - this is quite a challenge itself)
2. *One* interaction guaranteed to be protected from a MiTM for key exchange
3. An encryption protocol which isn't broken

#3 is easy. There are multiple options available.
#2 can be easy, if you live just down the road from the person you want to have secure communication with. It can also be hard if you can never meet the intended recipient.
#1 is a nightmare, unless you build the device and the OS yourself.

The actual communication path can be anything from public radio broadcast to RFC1149, so long as the endpoints are trusted, the encryption protocol isn't broken, and your key exchange hasn't been intercepted (or keys stolen, but that is a trusted endpoint issue)

Who's stopping you from using a TXT record for that?

For rDNS'ing phone numbers, we have .e164.arpa.

Actually I think there should have been three possible values for that header. User has opted in, user has opted out, and user has not taken initiative to change anything on his own. That would leave the default choice up to the websites, which I consider better than leaving the default choice up to the browser vendor. But more importantly, it would have made the semantics of the header slightly more clear than a boolean.

I wonder if this kind of thing pops up anywhere else?

I took a closer look at the standards draft: http://tools.ietf.org/html/draft-mayer-do-not-track-00

Turns out there are actually three different possibilities. The browser can send "DNT: 1", "DNT: 0", or leave out the header. A server cannot distinguish between clients that leave out the header and those that simply don't support it. Then I noticed this unfortunate wording in the draft:

A user agent MAY adopt NO-EXPRESSED-PREFERENCE or OPT-OUT by default. It MUST NOT transmit OPT-IN without explicit user consent.

If you permit opt-out as the default, then it isn't opt-out. So Microsoft is not violating the draft standard, they are using an option that the authors put in there. I don't think the authors have fully considered the implications of their wording. And Microsoft should still backtrack on their decision given the criticism they received. I do however hope the authors of the document realize they are at least partially responsible for this mess and they update the draft to clarify the intention.

chances are, you were dumber in 1985

Unlikely, unless he regressed from 1984 to 1985.

I would suggest that you really should be looking at your security policies to see if they make sense. DDNS with TSIG or SIG(0) is as secure if not more so than whatever script you are running. This is a decade old technology that has been used in some of the biggest companies in the world, read "Fortune 100" and bigger.

I would suggest that you really should be looking at your security policies to see if they make sense. DDNS with TSIG or SIG(0) is as secure if not more so than whatever script you are running. This is a decade old technology that has been used in some of the biggest companies in the world, read "Fortune 100" and bigger.

I would suggest that you really should be looking at your security policies to see if they make sense. DDNS with TSIG or SIG(0) is as secure if not more so than whatever script you are running. This is a decade old technology that has been used in some of the biggest companies in the world, read "Fortune 100" and bigger.

> If you need a /8 for private addresses, use 10.0.0.0/8. That's what it's bloody there for.

RFC1918 space wasn't always there. No doubt if you looked at the history behind most classic Classful A and B assignments you'll find that they existed before RFC1918 (February, 1996). Case in point: 51/8 was assigned August, 1994.

Places that obtained IPv4 addresses should not just give them up and switch to 10/8 to band-aid the IPv4 problem that is still going to exist. Public IPv4 space is exhausted for APNIC and RIPE. It's time to move to the solution: IPv6.

RFC1918 date source: https://tools.ietf.org/html/rfc1918
51/8 allocate date source: https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks

It's called stateless address autoconfiguration.

http://www.ietf.org/rfc/rfc2462.txt

Also, I think they should modify all future browsers to use extra caution when opening a file called "exploit.html" . In retrospect, it seems so obvious...

No need... a properly configured firewall will do it before the browser gets the page

Hash codes can still be sent around on "sneaker net" and other ways to ensure that Bitcoins can be transmitted to each other.

You don't need a 24/7 internet connection, all you really need is the ability to get your transactions processed eventually on the global network. Eventually means just that... it just has to be incorporated into the larger chain when it becomes convenient. As long as everybody acting locally agrees upon the values being exchanged there isn't even a loss of value among the bitcoins being exchanged. About the only thing "lost" is the ability to "coin" new Bitcoins and to receive payments for processing transactions as that sub-net will not be participating with the global network until it reconnected.

It is also possible to set up a "local network" that would be processing the payments between users using the regular Bitcoin system. It would need to be noted that such a local network would be in effect a different "bitcoin" currency though in terms of coining new bitcoins and payments received. That is something to keep in mind too.... there can be more than one Bitcoin network. In fact, there is a "test network" that has a different "root block" which is being used only for testing the Bitcoin network ideas and isn't really taken seriously by the rest of the developers as having value. You can set up your own "root block" if you care to only transmit values between close friends. Good luck on getting your own private Bitcoin accepted by anybody else though. In an extreme situation such private Bitcoin currencies certainly could be created (such as an independent Bitcoin network on Mars). There would obviously be an exchange rate between the alternate Bitcoin and the main "Earth" or "global" Bitcoin, but such alternate currencies certainly could be created.

Double spending can't happen because the subsequent attempts at making a purchase (or rather transferring the Bitcions) would be invalidated and wouldn't actually happen. The person "receiving" the Bitcoins might be pissed, but that is between you and the person who thought they were getting paid and didn't. Verification that the 2nd person didn't receive the Bitcoins is public knowledge, as it is in the Bitcoin chain itself and can be verified.

As for how to transmit information about transactions for eventual incorporation into the global transaction chains, you could use a system similar to RFC 1149. This system has been implemented in the past, and certainly could be used for transmitting transaction information instead of just Internet Protocol packets instead.

All of this of course would take somebody who knows the Bitcoin protocol very well, but it isn't impossible.

It is also possible to "print" Bitcoins as paper currency, but that is a whole other subject.

Network Working Group
Request for Comments: 3514
Category: Informational

                  The Do Not Track Flag in the IPv4 Header

Status of this Memo
      This memo provides information for the Internet community. It does
      not specify an Internet standard of any kind. Distribution of this
      memo is unlimited.

Copyright Notice
      Copyright (C) The Internet Society (2013). All Rights Reserved.

Abstract
      Advertisers, marketers, data aggregators, and the like
      often have difficulty distinguishing between people that have
      money and those that are merely unusual. We define a
      Do Not Track flag in the IPv4 header as a means of distinguishing
      the two cases.

Read more at http://www.ietf.org/rfc/rfc3514.txt

One final thought: an Internet where every single IPv4 address does not go to waste is probably difficult to achieve for technical reasons.

That's what the HD-ratio is all about. The HD-ratio is a measurement of what percentage of the bits in the address you can efficiently use. It turns out in practice that things tend to go well if the HD-ratio is less than 80%, between 80% and 90% is where you plan how to extent the address space, and if you go above 90% it means your plan failed.

Why not just use IPv9

RFC 1606: http://tools.ietf.org/rfc/rfc1606.txt

Oh no! Is the IETF on the same updating scheme as Mozilla?

Why not just use IPv9

RFC 1606: http://tools.ietf.org/rfc/rfc1606.txt

none other than Bruce Perens (Open Source champion) points us to these: https://datatracker.ietf.org/ipr/1520/ https://datatracker.ietf.org/ipr/1741/ wherein we learn that Opus is "possible royalty/fee". this is not consistent with "Fully Free" to any patent troll waiting for broad adoption before jumping.

none other than Bruce Perens (Open Source champion) points us to these: https://datatracker.ietf.org/ipr/1520/ https://datatracker.ietf.org/ipr/1741/ wherein we learn that Opus is "possible royalty/fee". this is not consistent with "Fully Free" to any patent troll waiting for broad adoption before jumping.

the standard does not specify a recommended container format

See the Opus Ogg mapping for more details. Of course, if people want to use other containers, we're not a container police.

Support for more than 2 channels is done at the container level, although the Opus format already has the framing planned. See http://tools.ietf.org/html/draft-terriberry-oggopus for more details.

Choosing to ignore a standard is not what they should be doing either.

To be honest this is kind of a ridiculous standard anyway. The way I read it, it seems to me the sites I would least want to track me are the exact sites that are most likely to ignore DNT completely. This standard reminds me of the Evil Bit RFC.

There are options that allow you to detect MiTM SSL interception attacks by allowing you to verify the CERT being returned by a path that is not vulnerable. See: DANE.

No you don't. See The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA.