An article in CircleID reference a report [PDF] by Core Competence and Nominet that talk about support of DNSSEC in routers for residential use. The report point out problems some of those routers have, specifically in their NAT and Firewall functionality, if the end user behind this router do issue queries that request DNSSEC signed data back. What one have to remember is that the normal setup (as is said in some comments to the CircleID post) is that these queries are not sent in the first place. Instead queries are sent to the DNS resolver on the outside of the firewall/nat, and then that box is doing the DNSSEC verification. There is an implicit trust between the box sending the initial query and the resolver on the outside. Sure, in the future, also the boxes on the inside with start verifying DNSSEC signed data, but, not today, and I am pretty sure these boxes will be updated and have such features tomorrow. All of them, and not only the ones that do have such features already. As I say in the title of this post, I think the result was good. I am positively surprised over the high level of DNS functionality that exists in these tiny boxes that, once again, is for residential use. Updated: It seems the meetings in Geneva make me more tired than what I thought. I am now looking into more of the details of the report, and it seems to be worse than what I thought at first. I will of course update when I finally made up my mind on this… […]
An article in Wired today interview a number of people about DNSSEC. The conclusion of the article is that they all think the root zone should be signed, and that one of the major obstacles today is the part of the US Government that overlook changes to the root zone. The one that have the contract with ICANN. Many of my domains are in the .SE TLD, that is signed with DNSSEC. The problem is of course that not many resolvers do verify DNSSEC signed responses. Not before the root is signed. I personally definitely think it is time to sign the root zone. […]
A security update to MacOSX is now released. Among other things it updates the DNS software Bind according to this notice you can see below. An update that is really important to install given that we just started to see effective attacks using this attack vector:
BIND CVE-ID: CVE-2008-1447 Available for: Mac OS X v10.4.11, Mac OS X Server v10.4.11, Mac OS X v10.5.4, Mac OS X Server v10.5.4 Impact: BIND is susceptible to DNS cache poisoning and may return forged information Description: The Berkeley Internet Name Domain (BIND) server is distributed with Mac OS X, and is not enabled by default. When enabled, the BIND server provides translation between host names and IP addresses. A weakness in the DNS protocol may allow remote attackers to perform DNS cache poisoning attacks. As a result, systems that rely on the BIND server for DNS may receive forged information. This update addresses the issue by implementing source port randomization to improve resilience against cache poisoning attacks. For Mac OS X v10.4.11 systems, BIND is updated to version 9.3.5-P1. For Mac OS X v10.5.4 systems, BIND is updated to version 9.4.2-P1. Credit to Dan Kaminsky of IOActive for reporting this issue.
I have written earlier about Bidi issues here and here. I have here two more examples, and after these examples I hope people understand this is a real issue. In the first example, you see that although the normal domain name 2est.com is a legitimate domain name that can be delegated, if one delegate from that zone a domain name that ends with a character with Left to Right directionality, it will change place with the number). In the second example, you see two different strings (different logical order) that are rendered the same way. So after rendering you can not know which one of the two logical strings that was the origin. The reason we have all of these problems is because the separator between the labels (‘.’) is not immutable. If it was, characters would not “jump” as there are across the boundary. What is interesting to see is that the boundary in the DNS protocol is not a period as the labels are stored completely independently as length prefix strings. Further, in operating systems the labels are also in many cases separated from each others. With scroll bars, dialog boxes etc. So what to do? And why does this happen? We have to go back to the Unicode Bidirectional Algorithm. If we look closely it is even recommended to include an explicit direction mark if a separator like period is to be really be a separator. In this case, adding U+200E LEFT-TO-RIGHT MARK before the period do the trick. But to do this as part of the rendering algorithm, one have to know that it is a domain name that is displayed, and that is by far not always the case. In free flow text for example. How many are adding the angle-brackets ” around URLs in email? And on top of this, we have the question on the overall order of labels. Should a domain name www.example.com in a right to left context be written as com.example.www or www.example.com? All hard questions, and while resolving them, I think we can change the speed of light as well. Thanks specifically to Stuart Cheshire for the discussions leading to this specific post. […]
I showed yesterday what the implication is when one mix Right to Left and Left to Right characters in specific contexts. That was explicitly in a Left to Right context. Today I was thinking of showing the difference between different context, but the same logical order of the characters. In the examples, I in both cases typed in the characters in this logical order (left to right). The # represents U+0628 ARABIC LETTER BEH. When this is displayed in a Left to Right context, the displayed string looks like the following: But when this is in a Right to Left context, the result is the following: […]
This is an example of what happens when I in MacOSX create directory paths with characters of mixed right-to-left and left-to-right directionality. What create the problems are the numerals that are adjacent to the path separator. The example is of a problem that is discussed at the moment in the IDNA working group in the IETF. Documents that describe the issue can be found on the https://stupid.domain.name/idnabis/ website where documents are updated when posted. Updated: I should clarify that this example is when the overall context is left-to-right. I will come back with an example that also show difference between right to left and left to right contexts. […]
So I wrote earlier that I though it was good stuff when ICANN released a paper on DNS Security. Yes, I think it was good this paper was released, and yes it points out correctly how important DNSSEC is. But, now when reading it in detail, I find two things that troubles me. And it has to do with management of .ARPA. A top level domain that is used for infrastructural purposes. Like IP-addresses and E.164 numbers. The first paragraph that I have some issues with is this:
Production deployment of DNSSEC-signing of .ARPA, and a possible ICANN role in DNSSEC-signing of the root zone will involve planning with and approval by the U.S. Department of Commerce under the IANA functions contract.
IAB has in this correspondance with IANA requested some domains be signed, among them .ARPA, but here ICANN states that this requires approval by US Government. Second paragraph that I have issues with is this:
13. With respect to .ARPA, staff have completed development work and are currently developing an operational plan for DNSSEC deployment which includes, among other elements, selection of secondary DNS providers with specific service level agreements.
Given the long history of debates on what should go, and what should not go in contracts with ICANN, this makes me a bit more nervous than what it calms me down. It is good that people agree on how DNS is to be run, but if contracts and agreements are too focused to the legal situation in one legislation (i.e. the USA), then I think the process is a failure. ICANN is an international organisation, although based (like any organisation) under one jurisdiction. It must because of this work very hard, harder than today I think, in ensuring it is possible for organisations from all over the world, on equal terms, can participate. Just the fact there has been an ongoing discussion whether that is the case for the agreements accredited registrars have to go through make me rise my eye brows for this paragraph. You can see what view the IAB has on the technical parameters of IANA here in some correspondence with DoC related to the ICANN/DoC Joint Project Agreement, and the question now is of course what the situation is in reality. And what will happen next. […]
Today ICANN releases a paper with the title DNSSEC @ ICANN — Signing the root zone: A way forward toward operational readiness. The paper explains in more detail than earlier documents what ICANN view on signing of the root zone is. I think the key points mentioned in this paper are true, and in general, I think this document is a good read. It is not long, and summarizes what I would call the current view is. There have been some recent discoveries of threats to DNS. All described for example in CERT VU#800113. More information about these issues has now leaked and we have already some exploit code. For example CAU-EX-2008-0003. We also have data from Austria that show that a too low percentage of resolvers are upgraded. And further that the upgrade of software is not going as fast as one would hope. (Thanks Otmar et al for good work!) No single detail in the attack is really new, but the combination of things is new, and the situation scares me. The fixes suggested (like upgrading Bind to a version that is secure according to column 29 in the BIND Vulnerability Matrix) is bringing us back to a situation where we thought we where. But the real solution is to digitally sign the data in DNS, and secure the full path between querying client and authoritative server. DNSSEC is today a solution to a large piece of that, but it also have to be deployed. And the ICANN document just released is because of that good stuff. […]
Last draft I finished today is the one I am editing on behalf of the Internet Architecture Board on how to expand the DNS to hold new kind of information. Far too many people add new data by just storing data in TXT Resource Records. That is for many reasons not an optimal solutions. In this document IAB try to list the various pros and cons with the various mechanisms. The document also try to convince the reader that adding a new resource record type is not as hard as rumors say. You can see the new draft here, and the differences between -05 and -06 here.
Title : Design Choices When Expanding DNS Author(s) : P. Faltstrom, et al. Filename : draft-iab-dns-choices-06.txt Pages : 18 Date : 2008-07-14
I have also posted a new version of my draft on generation of a property value for Unicode Characters. The property value is to be used for decision on whether the character can be used in an internationalized domain name (it is not the only requirement). One can find the draft here, and a diff from the -01 version here.
Filename: draft-ietf-idnabis-tables Revision: 02 Title: The Unicode Codepoints and IDNA Creation_date: 2008-07-14 WG ID: idnabis Number_of_pages: 58