Slashdot Mirror

Well, the people that build the Internet Protocols agree with you:

"Newly designed protocols should prefer encryption to cleartext operation. There may be exceptions to this default, but it is important to recognize that protocols do not operate in isolation. Information leaked by one protocol can be made part of a more substantial body of information by cross-correlation of traffic observation. There are protocols which may as a result require encryption on the Internet even when it would not be a requirement for that protocol operating in isolation.

We recommend that encryption be deployed throughout the protocol stack since there is not a single place within the stack where all kinds of communication can be protected.

The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations, and to make them encrypted by default. We similarly encourage network and service operators to deploy encryption where it is not yet deployed, and we urge firewall policy administrators to permit encrypted traffic."

https://www.iab.org/2014/11/14...

W3C also had a similar statement I can't seem to find right now.

W3C for example is developing policy certain features will only be available when the website uses HTTPS:
https://w3c.github.io/webappse...

Or you want attackers to inject extra code in a webpage where you enable your webcam ? I would think not.

I'm really going to miss being able to telnet to a server and troubleshoot using plain text. Feels like a lot of simple has disappeared from the internet

Yes, HTTP/2 is a multipllexing binary framing layer, but it has all the same semantics of HTTP/1.x on top.

HTTP/2 is 'just' an optimization. So if your webserver supports HTTP/1.x and HTTP/2 then you can still use telnet to check whatever you want and it should give the same result as HTTP/2.

But you also have to remember:
The IETF which is the group of people who design the Internet protocol made this statement:
https://www.iab.org/2014/11/14...

"Newly designed protocols should prefer encryption to cleartext operation."

The W3C made a similar statement, there are also drafts with the intention to moving to HTTPS by default.

So it is all moving to TLS protocols like HTTPS or STARTTLS for SMTP anyway. Those are clearly not text protocol either.

So even if you want to interact with the text protocol used inside that TLS-encrypted connection, you'll need to use a tool because netcat or telnet won't cut it.

Let's look at HTTP, because this is a HTTP/2 article.

That tool could be the openssl s_client, but as you can see that is kind of cumbersome:
echo -en "HEAD / HTTP/1.1\nHost: slashdot.org\nConnection: close\n\n" | openssl s_client -ign_eof -host slashdot.org -port 443 -servername slashdot.org

But I suggest you just use:
curl -I https://slashdot.org/

The main developer for cURL works for Mozilla these days and is one of the people working on the HTTP/2 implementation in Firefox and is writing a document explaining HTTP/2: http://daniel.haxx.se/http2/
So as you would expect Curl supports HTTP/2:
https://github.com/http2/http2...

Basically every browser include 'developer tools' which will also let you see the headers and everything else you are used from HTTP/1.x.

I would rather see we all move to using encrypted protocols then that we can still use telnet.

Note that this move is broader than just ICANN. IANA functions are actually run in close coordination with a number of organisations, for instance, regional internet registries (RIRs) and IETF who decide about address allocation policies and protocol number allocations.

Here are some initial reactions from all of these organisations:

http://www.iab.org/documents/c...

My heart almost sank until I realized IAB != IAB

Good IAB: http://www.iab.org/
  Bad IAB: http://www.iab.net/

For a moment I though IAB what the IAB...

Root wildcarding considered harmful.

You meant to say SPF and DKIM.

"senderID" was an unsuccessful non-standard created by Microsoft hijacking SPFv2 with submarine patents and other deceits. Read up on MARID and see what I mean. senderID is dead, do not try to implement it, do SPFv1 or domainkeys if you want the current gold standard.

DKIM is the successor to domainkeys, and it's looking pretty good.

There is no "easy" involved in crypto, however. If you want "easy" do SPFv1... spoofing prevention with 5 minutes of work by any competent DNS administrator.

ISOC Official Page
IETF Official Page
IESG Official Page
IRTF Official Page
IAB Official Page
RFC Editor Official Page
ICANN Official Page
IANA Official Page
W3C Official Page
W3C encyclopedia article
ICANN encyclopedia article
IANA encyclopedia article

• ISOC Official Page
• IETF Official Page
• IESG Official Page
• IRTF Official Page
• IAB Official Page
• RFC Editor Official Page
• ICANN Official Page
• IANA Official Page
• W3C Official Page
• W3C encyclopedia article
• ICANN encyclopedia article
• IANA encyclopedia article

ISOC Official Web Page

IETF Official Web Page

IESG Official Web Page

IRTF Official Web Page

IAB Official Web Page

RFC Editor Official Web Page

ICANN Official Web Page

IANA Official Web Page

W3C Official Web Page

W3C encyclopedia article

ICANN encyclopedia article and IANA encyclopedia article

ISOC Official Page IETF Official Page IESG Official Page IRTF Official Page IAB Official Page RFC Editor Official Page ICANN Official Page IANA Official Page W3C Official Page W3C encyclopedia article ICANN encyclopedia article IANA encyclopedia article

The Internet Architecture Board has recently written a document (draft-iab-identities) which covers how DNS names are used as identities and why doing things like what verisign was trying to do is a bad thing. They don't outright specify this particular battle, but talk about it in a more generic sense.

The slashdot article suggest that a standard was broken. It is not, and the editorial does not mention it. For the record, the Internet Architecture Board wrote:

"We must emphasize that, technically, this was a legitimate use of wildcard records that did not in any way violate the DNS specifications themselves. One of our main points here is that simply complying with the letter of the protocol specification is not sufficient to ensure the operational stability of the applications which depend on the DNS: there are protocol features which simply are not safe to use in some circumstances." -- IAB Commentary: Architectural Concerns on the use of DNS Wildcards

Last, contrary to what VeriSign claims, it DOES break (parts) of the Internet. See all examples mentioned in the IAB advisory above. For example, consider what happens if you type "myprinter.mydoman.com" instead of "myprinter.mydomain.com" in your CUPS configuration. Without the wildcard, you get a simple message that you made a typo. With the wildcard, you have a hell of a job finding out why you can't connect to your printer.

"We must emphasize that, technically, this was a legitimate use of wildcard records that did not in any way violate the DNS specifications themselves. One of our main points here is that simply complying with the letter of the protocol specification is not sufficient to ensure the operational stability of the applications which depend on the DNS: there are protocol features which simply are not safe to use in some circumstances."

It's neither. It's a DNS issue. Full stop.

Here, have a loot at the IAB's point of view. They make a powerful case against the use of wildcarding in top level zones. The big thing is that it breaks a whole lot of protocols. HTTP isn't really that big a deal. ISPs could easily handle that in their DNS systems. Currently there are so many public and private protocols being used that nobody, not even Verisign, can properly provide for them using a wildcarding sytem, yet that is what Verisign is actually doing. And they are doing it very badly.

It increases network traffic, incurring more cost to ISPs and consumers. It makes it very difficult to present proper error codes for protocols that Verisign did not anticipate such as IRC. It breaks old protocols for which clients are not being developed but still provide a valuable function. For protocols that are still supported, it incurs higher costs for those users since the developers will need to update their software. There are so many problems with wildcarding that even the IAB gave up listing them after a dozen or so.

As Paul Vixie said, the major problem here is one of broken expectations. The .com and .net domains have behaved in the non-wildcard manner since day dot. There is a reasonable expectation that a DNS query on a non-existent .com or .net domain will return a "no such domain" response. VeriSign unilaterally broke this without warning. I believe that ".museum" has implemented the wildcard since day dot, so there are no broken expectations there. As the IAB said, it's reasonable to implement wildcards with the informed consent of everyone who is delegated a name in that zone (but it's still a bad idea, technically, for various reasons).

• Read this and this before you panic
• ask your ISP for patching bind (or whatever ns-software they use)
• install a patched bind (djbdns, ...) locally as a caching dns
• if you have no chance of using a patched nameserver (why that?), you may reject (not: drop) 64.94.110.11:80/tcp only and install one of those patches to your MTA (postfix, sendmail, ...)
• if you are customer of verisign, ask them for suspending their new "service"

To quote:

Proposed guideline: If you want to use wildcards in your zone and understand the risks, go ahead, but only do so with the informed consent of the entities that are delegated within your zone.

Generally, we do not recommend the use of wildcards for record types that affect more than one application protocol. At the present time, the only record types that do not affect more than one application protocol are MX records.

For zones that do delegations, we do not recommend even wildcard MX records. If they are used, the owners of zones delegated from that zone must be made aware of that policy and must be given assistance to ensure appropriate behavior for MX names within the delegated zone. In other words, the parent zone operator must not reroute mail destined for the child zone without the child zone's permission.

We hesitate to recommend a flat prohibition against wildcards in "registry"-class zones, but strongly suggest that the burden of proof in such cases should be on the registry to demonstrate that their intended use of wildcards will not pose a threat to stable operation of the DNS or predictable behavior for applications and users.

We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity.

...and hang tough.

After all, the IAB says here that "We must emphasize that, technically, this was a legitimate use of wildcard records that did not in any way violate the DNS specifications themselves."

If the decision-makers at Verisign cared about good engineering practice, they wouldn't have done what they did.

They probably regard their own actions as just "sharp business practice" and are probably patting themselves on the back for having found a loophole in the DNS specification that they can use for their own profit.

I don't think jawboning from ICANN, the IAB, or anyone else will have much effect. I don't see how anyone short of the Feds can stop them.

I mean, they have contracts with their SiteFinder advertisers. There's money at stake here.

The IAB statement in response to Versign has a lot of technical background on DNS wildcards, what they are, and what the problems with their use are.

The IAB has issued a set of guidelines for the us of DNS wildcards.

Essentially, they say it's a very bad idea, but you can do it with the informed consent of all delegates in your zone.

That's because the slashdot editors didn't check the story... nothing new there.

The correct link is here

I believe you want the 2003-09-20 IAB response to Verisign (written 2003-09-19). It's reasonably thorough in listing all the problems caused by wildcards.

Mark Handley, IAB.

The messages referenced in the article are from January and concern a different (equally stupid) Verisign proposal. The IAB's comments on Verisign's current actions can be found here.

The response in the orignal article links to something old. Here is the IAB's offical reponse. The bottom has a whole section on "Principles, Conclusions, and Recommendations" Good reading http://www.iab.org/documents/docs/2003-09-20-dns-w ildcards.html

ICANN should demand that VGRS immediately stop giving incorrect answers to any query in .com and .net, and should instead follow the IETF standards. If VGRS refuses, ICANN should re-delegate the .com and .net zones to registries that are more willing to follow the DNS standards. Please let me know if you have any further questions. --Paul Hoffman, Director --Internet Mail Consortium

"The Internet Architecture Board issued this response to an ICANN inquiry about Verisign's SiteFinder service."

Actually, if you read that article you will find that it is dated January 25 and is a response to another Verisign screwup. That one was similar to the present one, but had specifically to do with "internationalized" domain names -- DNS records for strings with characters above ASCII position 127.

Historians find it important to check the dates of events and documents, so they can know which ones could possibly be responses to which other situations. For instance, an American comedian telling anti-French racial jokes in August 2001 could not possibly be responding to the French objection to Bush's war. Similarly, a document released January 25 2003 cannot be a response to a situation that arises the following September. Time just doesn't work that way.

Official response is here

Essentially, they state that this change violates the RFC for DNS for several reasons. They are creating an IETF working group to recommended practices for implementing DNS, above and beyond what the RFC requires. Unfortunately, there is no mention of any action, or even censure.

this effectively lets VeriSign get away with it.

As a BIND architect/deployer/admin I see that ISC is always getting bashed. Kudos to them for this creative patch, presented almost instantly compared to their usual release schedules. But, precisely, it let's Verisign get away with this action, which is horrible. Especially because this: http://www.iab.org/Documents/icann-vgrs-response.h tml
(which was posted in the first slashdot thread abot this topic), went unnoticed, and unheeded by Verisign.
Big business in this country is getting WAY out of hand with greed.

From: http://www.iab.org/Documents/icann-vgrs-response.h tml

Subject: Re: Request for Advice on VGRS IDN Announcement
To: "M. Stuart Lynn"
Cc: Leslie Daigle ,
Chuck Gomes ,
Brad Verd ,
Masanobu Katoh ,
Steve Crocker ,
Vint Cerf ,
Louis Touton ,
Andrew McLaughlin ,
iab@ietf.org
Date: Sat, 25 Jan 2003 10:19:37 +1100

Dear Stuart,

Thanks for your message. After reviewing the announcement, examining the behavior of the deployed system, discussing the issue with colleagues external to the IAB, and meeting with VeriSign's technical staff to go over the system's aim and implementation, the IAB has come to the following consensus.

The IAB feels that the system VeriSign had deployed for .com and .net contains significant DNS protocol errors, risks the further development of secure DNS, and confuses the resolution mechanisms of the DNS with application-based search systems. The IAB understands the efforts that VeriSign has made to limit the applicability of this system to queries which would normally not correspond to registered domains, and it recognizes the importance of the distribution of IDN-capable systems to end users. While the IAB agrees with VeriSign that rapid adoption of IDN-capable systems is desirable, the IAB feels that the very limited gain in distribution cannot balance the shortcomings of this deployment strategy.

The IAB has begun the process of shepherding the creation of an Informational RFC on concerns with operational practices with the DNS. We anticipate discussing the issues raised in your notes in more detail as part of that document. Given the scope of the issue, and our desire to ensure that it will have adequate review by the (DNS) operational community, we will be enlisting the help of the broader IETF community through relevant IETF working groups. In advance of that document, we have outlined below the issues with the VeriSign system which led us to the conclusion above.

As a lookup system, the DNS is designed to provide authoritative answers to queries. The DNS protocol specifies behavior for queries whose targets do occur in a zone by describing the data format for the specific resource records and the wire format for the response. The DNS protocol also specifies behavior for queries whose targets do not occur in a zone by describing the wire format for a negative response.

The system deployed for .com and .net does not follow the specification for targets not in a zone. Instead, it examines the target and decides whether to give the specified negative response or a synthesized record based on whether the target contains a code point above 127. This is a violation of the DNS protocol as described in RFC 2308, Section 2.1. While it is possible within the DNS protocol to include wildcard records which cover all queries not otherwise specified by a zone, this is not what VeriSign has done. Negative answers for records which do not contain code points above 127 continue to be sent.

It would, of course, be theoretically possible to add zone entries for all records containing code points above 127. Given that the Verisign system does not recognize "." as a label delimiter for testing these records, the size of the resulting zone is unimaginably large. VeriSign confirms that they are not managing a zone of the size this would imply and is, instead, synthesizing these entries. This implies that the zone as currently served by VeriSign cannot be transferred using either AXFR or file transfers in master file format. Though the choice of who may employ AXFR or file transfer to get copies of a zone is a policy decision, the IAB notes that the current system does

I was getting worried there for a moment... I couldn't figure what the Internet Architecture Board was doing wanting to INCREASE Internet advertising. Maybe making a recommendation for the IETF to investigate a protocol enhancement to be able to easily identify ads for blocking... but definately not increase them!

It is *not* the Internet Architecture Board, it is the Internet Advertising Bureau. Could you imagine it being different?

Yeah, yeah, it's redundant. But that's what came to my mind when I read IAB on the title.