In the three years since IETF said pervasive monitoring is an attack, what's changed?

IETF Security director Stephen Farrell offers a report card on evolving defences

Feature After three years of work on making the Internet more secure, the Internet Engineering Task Force (IETF) still faces bottlenecks: ordinary peoples' perception of risk, sysadmins worried about how to manage encrypted networks, and – more even than state snooping – an advertising-heavy 'net business model that relies on collecting as much information as possible.

In a wide-ranging 45-minute, 4,000-word interview (full transcript in this PDF), IETF Security Area Director Stephen Farrell gave a report card of what's happened since the Internet Architecture Board declared that “pervasive monitoring is an attack”, in RFC 7258. Much of the discussion used Farrell's presentation to the NORDUnet conference in September, and the slides are here.

Let's boil the ocean, so we can cook an elephant. And eat it.

Given the sheer scale of the effort involved – the IETF's list of RFCs passed the 8,000 mark in November – nobody expected the world to get a private Internet quickly, but Farrell told The Register some of the key in-IETF efforts have progressed well: its UTA (Using TLS in Applications), DPRIVE (DNS Privacy), and TCPINC (TCP INCreased security, which among other things is working to revive the tcpcrypt proposal rejected earlier in the decade).

UTA: The idea is to get rid of the nasty surprises that happen when someone realises a standard (and therefore code written to that standard) still references a “laggard” protocol – so, for example, nobody gets burned complying with a standard that happens to reference a deprecated SSL or TLS standard.

“The UTA working group produced RFC 7525 (Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), https://tools.ietf.org/html/rfc7525 here). The last time I looked, there were something like 50 RFCs that are referencing that [The Register checked this list, provided by Farrell – it seems to be close to 70 already].”

The idea of UTA is that a protocol written 10 or 15 years ago should be updated so it no longer references the then-current version of TLS, he said.

“That's being used in order to provide a common reference: as people update their implementations, they'll reference a more modern version of TLS, currently TLS 1.2, and as TLS 1.3 is finished, we have an automated-ish way of getting those updates percolating through to the documentation sets.

“That's quite successful, I think, because it normalises and updates and modernises a bunch of recommendations.”

DNSPRIV: Readers will recall that IETF 97 was the venue for the launch of Stubby, a demonstrator for securing DNS queries from the user to their DNS responder.

Stubby, a demonstrator of DNS privacy work

That, Farrell said, is a good example of where DNSPRIV is at – on the user side, it's ready for experimental code to go into service.

“DNS privacy is something that is ready to experiment with. The current work in DPRIVE was how to [secure] the hop between and the next DNS provider you talk to.

“That's an easy problem to tackle – you talk to that DNS resolver a lot, and you have some shared space, so the overhead of doing the crypto stuff is nowhere.”

Getting upstream to where DNS queries become recursive – your ISP can't answer, so they pass the query upwards – is much harder, he said.

“Assuming that [the ISP] needs to find “where is theregister.com?”, he'll eventually talk to the UK ccTLD, and then he'll go talk to .co.uk and then he'll go talk to theregister.com – it's forking the communications a lot more, and it's a little harder to see how to efficiently amortise the crypto.

“The DPRIVE working group are now examining whether they think they can produce some technology that will work for that part of the problem.”

TCPINC: Some of the questions in this working group may never be seen by ordinary Internet users, but they're still important, Farrell said.

“I think we're close to having some TCP-crypt-based RFCs issued, there's been code for that all along. Whether or not we'll get much deployment of that, we'll see.”

“I think there are a bunch of applications that maybe wouldn't be visible to the general public. Let's say you have an application server that has to run over a socket – an application that runs on top of the Linux kernel, say, where you have to use the kernel because of the interfaces involved, and you can't provide the security above the kernel because you need it inside.

“That's where TCPINC fits in. Storage – they have really complex interfaces between the network-available storage server and the kernel, and there's lots of complex distributed processing going on.”

That's important to “the likes of NetApp and EMC and so on”, he said: “For some of those folks, being able to slot in security inside the kernel, with TCPINC, is attractive. Some, I might expect, will adopt that sort of thing – but it may never be seen on the public Internet.”