DNS Privacy – krypterad DNS

I en serie poster tänkte jag nu framöver posta lite mer renskrivna texter om DNS från mina anteckningar på olika internet-konferenser. Jag hoppas detta kan vara till glädje för någon som är intresserad av vad som händer i DNS-världen.

DNS har funnits i drift i över 25 år. Det är bara under de senaste 15 åren som säkerhet i protokollet diskuterats, och 2005 gick RFC:erna för DNSSEC genom IETF. Men kravet i protokollet för att skydda den personliga integriteten har aldrig funnits – förrän under det senaste året.

Med anledning av Edward Snowdens avslöjanden så har IETF sakta börjat se över de protokoll som IETF i någon form ansvarar för, och med publiceringen av RFC 6973, “Privacy Considerations for Internet Protocols” så kan man säga att arbetet satt igång på allvar. Inom IETF har man också satt upp en mailinglista för att diskutera “pervasive surveillance” med ett lite bredare perspektiv, perpass@ietf.org.

Gamla protokoll designades i en annan tidsålder, innan övervakning var på agendan. Dessa protokoll läcker mycket för mycket metadata (och data). Men det finns många begränsningar i dessa protokoll som kan förhindra eller försvåra att man gör tillägg för att gynna den personliga integriteten såsom latency, stabilitet och att protokollen blivit universella.

En DNS-fråga avslöjar vem som frågar, och vad som frågas efter. Detta underminerar säkerheten i andra protokoll, som till exempel HTTPS. Vad finns då i qname-delen av en DNS-fråga? “www.political-party.example”, eller “_bittorrent-tracker._tcp.domain.example” – MPAA kan vara intresserade. “le-pc-de-pascal.domain.example” – personlig information, eller t.ex. PGP-nycklar i DNS. Helt enkelt saker som avslöjar saker om ditt internet-beteende som de protokoll du använder dig av normalt kanske skyddar – men där informationen skickas i klartext i DNS. Detta beteende i DNS vill man ju ändra på.

Vi behöver en lösning för att skydda informationen “on the wire” och “på servern”. Resolvrar kan också läcka information genom t.ex. sysadmins, och en cache innehåller också all denna information i klartext. Att skydda DNS-informationen på protokollnivå kräver dock ändå olika lösningar, en för att skydda klient-kommunikationen mot en resolver, och en annan för att skydda kommunikationen från en resolver till auktoritativa namnservrar.

Från att ha diskuterats på perpass flyttade diskussionen till dnsop, och nu är flyttad till en egen dnsprivacy-lista. Det finns en möjlig lösning implementerad (men inga andra), DNSoverTLSoverTCP. Ingen officiell working group ännu, men vem som helst kan ändå posta förslag till IETF.

Problem statement: draft-bortzmeyer-dnsop-dns-privacy – problemet behöver dokumenteras innan man kan lösa det…

Minimizing the qname – fulla frågenamnet behöver inte skickas till auktoritativa namnservrar högre upp i hierarkin. Detta går att implementera i Unbound och BIND, men ingen har gjort det ännu. Påverkar DNS-OARC och DITL, eftersom informationen att göra forskning på minskar. Vilket ju också är lite av poängen…

Tyvärr förekommer det alldeles för lite diskussion om dessa förslag på listorna, och intresset verkar lågt (trots riktigt stora möten på IETF). Att förändra DNS är också väldigt svårt.

Efter förra helgens DNS-OARC-möte skickade Paul Vixie ett mail till IETF:s dnsop-arbetsgrupp och uttalat sitt stöd för minimering av innehållet i frågorna, så det arbetet kanske tar lite fart igen.

21
May 2014
POSTED BY
DISCUSSION 0 Comments
TAGS

Datorarkeologi

Det finns en hel del gamla saker man kan gräva i på Internet. Jag fick mitt lystmäte idag när jag gjorde lite undersökningar om varifrån vissa RFC:er ursprungligen kom ifrån. RFC 621 av Bill Ferguson verkar till exempel handla om hur man ska flytta vissa hemkataloger från en dator till en annan. Idag känns 1974 hyfsat avlägset, men en kvalificerad gissning är att Internet inte var så stort då:

On Friday evening 8-Mar-74, we will delete all those directories at SRI-ARC that belonged to NIC users who were transferred to OFFICE-1.

Innan DNS var man tvungen att kopiera hostfiler mellan datorerna. En annan härlig RFC handlar om hur man kan distribuera denna (“globala”) hostfil, och ifrågasätter varför det skulle vara så dåligt att använda FTP. Även detta 1974, ur RFC-625:

We are puzzled by the apparent distaste for FTP. In our opinion the goal has been to set up a network file transfer mechanism that everyone can use for a variety of needs without further programming required. If FTP is that bad, shouldn’t the criticism and work be directed towards improving or replacing it, rather than making end runs around it? FTP is surely more complex than is required for any particular application including this one, but isn’t that true by definition of a general facility?

Normalt sett blir jag nostalgisk av disketter.

08
Feb 2006
POSTED BY
POSTED IN IETF OldSchool
DISCUSSION 0 Comments
TAGS