techblog 

There are increasingly more applications which need to do more than simply have names resolved to addresses. There are methods needed to find zone-cuts (Mark Andrews’ SOA-discovery) for applications that want to update the DNS. DKIM uses DNS to store cryptographic material, etc etc. There is also DNSSEC, a whole layer of cryptographic data stored in the DNS to prove that the data stored in DNS is authentic. I’m sure there are many more.

The resolver needs to be as transparent as possible. It should not blindly or unknowingly restrict the application from functioning, and meanwhile it should have some ‘anti-spoof’ checking in place.

What follows is a small list of things needed for a resolver to be future-proof:

1) Support EDNS0 Maximum Payload Size.

DNS messages used to have a maximum payload size of 512 octets when transmitted over UDP. (This is the reason there are 13 root-servers in DNS, 14 would not fit in a response). If the server notices that the payload size is too small to store the necessary RRsets, it must set the TC (truncated) bit in the response. At this point, the resolver should re-query over TCP.

To avoid the extra latency involved in this fall-back scenario, the IETF standardized a method to advertise larger payload size. This advertising is done using EDNS0. EDNS0 defines a whole range of extentions for DNS, one of them is the ability to advertise maximum payload size. Technically, the resolver adds an record (OPT) to the additional section in a request or response. The payload size is stored in the CLASS field of the record.

This is a tradeoff. If the receiving side (a legacy nameserver) does not understand or expect OPT records or strange CLASS fields, the transaction will fail, causing the resolver to fallback to requery without the OPT record. Note that there might be a fallback yet again if the server responds with the TC bit.

Early deployment of EDNS (the standard which defines the OPT record) has seen a lot of these ‘fallbacks’: resolvers that use OPT, servers that do not understand them. But, currently the DNS is in a state where it is safe to assume that the server does. On the server side: Microsoft’s DNS server, ISC’s BIND and NLNetLabs’ NSD understand it. Older versions of some of these do not. Two other well known servers, PowerDNS (PDNS) and Dan Bernstein’s tinyDNS silently ignore the OPT record in requests, and respond anyway, so this won’t introduce a fallback either.

2) Ensure transmission of DNSSEC data.

DNSSEC provides for origin authentication and integrity cheking of DNS data using strong cryptography. All the cryptographic functionality resides in the zone-signer (code that signs data) and the validator (code that verifies responses). To show why this is, it’s useful to understand that the components of the resolver may be decomposed into five distinct and effectively independent functions: client (sending requests), server (receiving requests), resolver, cache, and validator. The resolver has in principal nothing to do with the cryptographic data. It just resolves and serves it. The server however must do some effort to find the proper data in its database (zonefiles or the like), but that is not too complex.

The resolver algorithm needs to do nothing at all with the cryptographic processing. This is done by the validator, preferably independent of the resolver algorithm. This allows an application to do its own DNSSEC validation. Note that this validator does not need to known anything about the resolving process nor the location of authoritative servers (NS, A and AAAA records). It has a trust anchor for some domain, and only cares about the DNSSEC data involved. It can query a resolver for DS and DNSKEY records, while the RRSIG and NSEC records are send back automatically.

To protect legacy resolvers, i.e., resolvers that cannot handle unknown data (more on that later), the request must include a signal to indicate to the server that it understands the presence of DNSSEC resource records. “understand” does not mean ‘able to validate’, merely that it will not be confused by these records.

This signal is called the DNSSEC-OKAY (DO) bit. It is allocated in the TTL field of the EDNS0 OPT record previously mentioned. It is basically the resolver signalling the server “send me DNSSEC data, if you have it”.

Since the resolver is now able to receive and store these DNSSEC records, applications can use it to validate DNS data.

3) Handle Unknown Data.

Without exception, all resource records have the same format: NAME, TYPE, CLASS, TTL, RDLEN and RDATA. There is no need for the resolver to understand that the RDATA of type 33 (SRV) has different semantics than the RDATA of type 44 (SSHFP). The syntax is of these records are identical. The type space is 16 bits wide, and only a handful of type codes have been assigned by IANA. There is only a tiny subset of types of which the resolver must know the RDATA semantics: SOA, NS, A, AAAA and CNAME.

4) Disregard and Remove Extraneous Data.

This section is about proper DNS hygiene. The resolver needs to protect client from potentially spoofed data. When a resolver queries a server, it is because it has learned that the server is authoratative for some domain in some class (typically the IN class). The resolver should therefore strip (not just ignore) all the resource records that have (1) a different class, and (2) a name not under the authority of the server. For example: a resolver connects to the authoritative nameserver for ‘.com’. When the resolver receives a response that contains names not ending with ‘.com’ (for instance: ns1.example.org A 127.0.0.1) it should remove them from the response before any other action. Note that the OPT record is only used to signal resolver and server capabilities and have no use outside of the actual transaction. After processing it, it should be removed as well.

Conclusion.

Some implementors sit on top of bleeding edge technology, others only implement if the demand for some technology is high. The latter approach is really a Catch 22. Applications can’t (and thus won’t) deploy new technology based on DNS if resolvers are not future proof. Resolvers won’t become future proof if there is no demand from the application side.

I believe it’s essential that all resolvers — especially the well-known ones — implement the principles listed above. I’d like to see organisations use future proof technology. This removes barriers to applications using DNS, DNSSEC, DKIM and whatever else is on the horizon.

Suppose you are away on a conference, say in Sao Paulo, and you haven’t set up VPN on your laptop but you need to access a server only accessible inside your corporate network. How do you do it?

Well all it takes is a host already inside your corporate network that you can ssh to because ssh has a clever facility built in to enable a tunnel through that computer.

Imagine I have an ssh host inside my network called ’ssh-host’ and the server I want to access is an intranet web server called ‘target’. Then all I need do from my laptop out in the wild is issue the following command

ssh -N -L 1234:target:80 myusername@ssh-host

And that will redirect port 1234 on my laptop to tunnel through to port 80 on the target server. To use it all I do is open up a web browser and go to http://localhost:1234 and hey presto the web page from the target server appears.

Just to talk through the command:

• -N This tells ssh not to execute a command on the remote server. This does mean that the ssh command does not appear to complete after you execute it in a shell but just sits there doing nothing. However it has worked. You will need to control-C to quit the ssh command.
• -L This tells ssh to create a tunnel.
• 1234:target:80 This tells ssh that the tunnel should be from port 1234 on the localhost to port 80 on the machine called target.
• myusername@ssh-host This is the username and host that sits inside the corporate network and provides the tunnel.

I wrote about installing a Araneus Alea I the other day. Since then I have been reading about how you test random number generators.

There is a discussion of this subject at Hotbits. This a web based random number generator that uses radioactive decay to generate the numbers. They have a program called ENT for testing binary data sequences.

Generating 1000000 random bytes with the Alea I can be done like this.

time ./randomfile -b 1000000 > /tmp/myrandom

real    1m21.073s
user    0m0.066s
sys     0m0.134s

Testing with the ENT program gives these results

./ent /tmp/myrandom
Entropy = 7.999817 bits per byte.

Optimum compression would reduce the size
of this 1000000 byte file by 0 percent.

Chi square distribution for 1000000 samples is 252.96, and randomly
would exceed this value 50.00 percent of the times.

Arithmetic mean value of data bytes is 127.5287 (127.5 = random).
Monte Carlo value for Pi is 3.144636579 (error 0.10 percent).
Serial correlation coefficient is 0.000713 (totally uncorrelated = 0.0).

According to the ENT manual this is very random data. Next I will be looking at what the NIST random number test tools have to say.

I just got a Areneus Alea I true random number generator going with OS X. The device will work with any Unix like OS that support libusb.
First get libusb from http://libusb.sourceforge.net/ and install it like this

./configure --prefix=/opt/libusb
make
make install

Then copy the contents of the driver CD that came with the Alea I somewhere you can write to.

cd linux
#edit the Makefile and make it look like this
randomfile: randomfile.c
cc randomfile.c -L/opt/libusb/lib -lusb -Wl,-framework
-Wl,IOKit -Wl,-framework -Wl,CoreFoundation -Wl,-prebind
-I/opt/libusb/include  -o randomfile

make

Then run the resulting randomfile program to see it work. Tests with this device will follow.

To get this working in FreeBSD you need to edit /boot/loader.conf and add the following lines

hifn_load="YES"
crypto_load="YES"
cryptodev_load="YES"

Reboot to make this take effect. (You may be able to use kldload to load the modules without rebooting)

Next add the utilities to test the card

cd /usr/src/tools/tools/crypto/
sudo make
sudo make install

Running hifnstats looks like this

hifnstats
input 6917304 bytes 9124 packets
output 6917304 bytes 9124 packets
invalid 0 nomem 0 abort 0
noirq 0 unaligned 0
totbatch 0 maxbatch 0
nomem: map 0 load 0 mbuf 0 mcl 0 cr 0 sd 0

You should see the card being used to accelerate ssh connections.

If you need to do any Cryptography in Java then you use the
Java Cryptography Architecture (JCA) and the Java Cryptography Extension (JCE) with a choice of implementation provider.

To validate PGP signed emails we have chosen to use the popular JCA and JCE provider from
The Legion of the Bouncy Castle. The Bouncy Castle software is free to use and is distributed under a license based on the MIT X Consortium license. The provider’s role is to provide the actual implementation for the API.

Bouncy Castle is a complete Crypto API for Java but unfortunately the lack of documentation and code examples don’t make it easy to use.

Installing The Provider

There are two ways to install the Bouncy Castle provider, you can either configure the JRE to preload the provider or do it dynamically at runtime.

To configure your JRE then edit the following file

jre/lib/security/java.security

and add the following line

security.provider.N=org.bouncycastle.jce.provider.BouncyCastleProvider

where N is the next available number.

To simplify deployment we tend to install the provider at runtime by adding the following line to a class constructor.


Security.addProvider(new BouncyCastleProvider());


Verifying Messages
Nominet receives messages from its tag holders which have been signed using their private key,
to verify a signed message we use the tag holders public key. The signed messages can be verified with Bouncy Castle using the following code example.

public  boolean
verifyFile(InputStream fileStreamIn, PGPPublicKey keyIn)
throws Exception
{
boolean verify = false;
ArmoredInputStream    aIn = new ArmoredInputStream(fileStreamIn, true);

//
// read the input, making sure we ingore the last newline.
//
int                   ch;
boolean               newLine = false;
ByteArrayOutputStream bOut = new ByteArrayOutputStream();

while ((ch = aIn.read()) >= 0 && aIn.isClearText())
{
if (newLine)
{
bOut.write((byte)'n');
newLine = false;
}
if (ch == 'n')
{
newLine = true;
continue;
}

bOut.write((byte)ch);
}

PGPObjectFactory pgpFact = new PGPObjectFactory(aIn);

Object o = pgpFact.nextObject();
if (o instanceof PGPSignatureList) {
PGPSignatureList list = (PGPSignatureList)o;
if (list.size() > 0) {
PGPSignature sig = list.get(0);
sig.initVerify(keyIn, "BC");
sig.update(bOut.toByteArray());
verify = sig.verify();
}

}

return verify;
}

The problems occur when Mail Transport Agents (MTA’s) add spurious white space to the email body after the message has been signed, this causes the message to fail the verification process since the message digests no longer match.

One solution is to strip the extra whitespace from the message using regular expressions, we have found the following Java regex’s work quite well for a large range of emails.

message = orgMessage.replaceAll(" *n", "n");
message = orgMessage.replaceAll(" *$", "");

The Problem:

We want to maintain a keyserver with the PGP keys of our customers. We should be able to add and delete keys from it as they are added to, and marked as “old” in, a database. There should be no human process required other than maintaining the database (which contains ASCII-armoured keys).

Attempt 1; using the PGPsdk (Version 1.7.1).

We have a script which builds, from scratch, a local keyring according to the database. So the first thing we tried was to modify this script to interact with a keyserver instead.

(ASIDE: There are a number of problems with using the PGPsdk. Routines are, in themselves, fairly well documented. However, there is no real indication as to how it all fits together. So, once you move away from something which is in their example code then you are really on your own.)

Now, in order to be able to delete keys you need an LDAP keyserver. We initially set up the PGP keyserver v7.0 provided by Networks Associates Technology, Inc. on Solaris8 (and windows).

Okay, so starting with the ability to add keys eventually we got something working. However, it would reject some keys when trying to add them to the keyserver. We did not actually get to the bottom of this one; but a quick look suggested that only “PGPsdk 2.0.1″ type keys worked… We can not say this for certain; what we can say though is that ALL the keys were successfully added to a keyfile built at the same time.

Putting that to one side we looked at deleting keys from the keyserver. This proved even less fruitful than adding keys did. The issue here is connecting with sufficient privileges to delete keys, which means connecting as an administrator. From the keyserver point of view it looks like you can assign connections from certain hosts/IP addresses as having administrator privileges; or you can use a shared key.

Despite all attempts we never managed to get this working. The only 2 ways we managed to delete keys was by 1) using the windows PGP client and 2) taking the nuclear option and deleting the keyservers data files. (NOTE: The PGPsdk has changed beyond all recognition between the version that we are using and the current version. We assume that the current keyserver and clients use the new sdk.)

Attempt 2; using the command line.

With the same keyservers we tried using the PGP and GnuPG command lines. Various versions were used but mostly PGP v6.5.8 and GnuPG v1.2.5; both on Linux. Oddly, trying the PGP command line does not work as it claims that whatever key you are trying to delete does not exist. The server logs show subtly different traffic for this transaction compared to a (successful) deletion from the windows client. gpg was even less successful; executing the commands on the same machine as the keyserver did not seem to help either.

We got in contact with the PGP Corporation about the new version of their command line. (Thinking that if it is built with the same version of the PGPsdk as the keyserver that it will have more chance of success.) To date they have not got back in touch (two months at the time of writing).

Attempt 3; fight the power.

Maybe a different keyserver could solve our problems? There are a number of open source keyservers out there; we tried “pks” and “cks” with little success.

There are other keyservers available but you have to draw the line somewhere.

Conclusion.

Because of the way that keyservers synchronise between themselves deleting keys is often futile; they get written back from other keyserver(s). This has led to little or no requirement for being able to delete keys (there are processes in place for the revocation of keys). So deletion is perhaps the least developed aspect of keyserver functionality.

The simplest way to achieve key deletion (without human intervention) is to delete ALL of the keys and rebuild the keyserver from scratch. This takes ~1/2 an hour for our 3,500 keys, which stops us from doing it during work hours.