The  Business  Case  for  DNSSEC  

Patrick  Hosein  Trinidad  and  Tobago  Network  Informa>on  Centre  (TTNIC)  

admin@nic.C    

ION  Trinidad  and  Tobago    Feb  5,  2015  

   

Overview  

•  Par>es  affected  by  DNSSEC  (Domain  Name  System  Security  Extensions)  

•  Quick  DNS  introduc>on  •  Flaws  in  DNS  •  Simplified  introduc>on  to  DNSSEC  •  Business  case  

DNSSEC  par>cipants:  •  Registries  (e.g.  .C)  and  Registrars  

–  Trinidad  and  Tobago  only  has  a  Registry  –  .C  has  already  deployed  DNSSEC  

•  Registrants  (especially  banks,  Government  etc.)  –  Major  incen>ve  is  security  

•  ISPs  –  Must  support  DNSSEC  resolvers  (benefit  to  customers)  

•  End  Users  –  Applica>ons  must  include  DNSSEC  support  

Business  case  

•  Companies/Government/Ins>tu>ons  are  very  concerned  about  cyber  security.  DNSSEC  is  a  weapon  in  this  fight  

•  Compe>>ve  Advantage  (ISPs/Banks  can  differen>ate  themselves)  

•  Poten>al  for  development  of  new  security  products  

What  is  DNS  •  Computers  communicate  via  numbers  called  IP  addresses  (e.g.  208.109.123.225)  just  like  phones  communicate  via  numbers  (e.g.  868.483.4454)  

•   Humans  prefer  to  use  names  but  with  phones  they  have  to  map  a  name  to  a  number  

•  In  the  Internet  the  The  Domain  Name  Service  (DNS)  does  this  mapping  (name  (www.nic.C)  to  address  (208.109.123.225))  transparently  

Simple  example  

•  You  type  www.gov.C  in  your  browser  

•  Your  computer  asks  a  nameserver  (e.g.  at  your  ISP)  to  determine  the  IP  address  

•  Your  ISP’s  nameserver  sends  out  various  queries  on  the  internet,  obtains  the  required  informa>on  and  returns  this  to  your  computer  

Simplified  DNS  Example  

1)  Resolve  www.gov.C  

Root  

ripe.nic.C  

dns5.gov.C  

2)  www.gov.C?  

3)  .C  nameservers  

6)  www.gov.C?  

4)  www.gov.C?  

5)  gov.C  nameservers  

7)  190.213.5.230  

8)  190.213.5.230  

What  is  the  problem?  

•  Can  we  trust  the  various  actors  involved  in  the  lookup?  

•  If  servers  or  communica>ons  (MITM)  are  compromised    then  my  computer  can  receive  an  incorrect  (planted)  address  for  my  requested  site  

•  This  incorrect  address  will  take  me  to  an  aCacker’s  fake  site  

Example:  DNS  Cache  Poisoning  

•  Resolvers  (e.g.  from  your  ISP)  cache  DNS  responses.  

•  An  aCacker  can  fake  response  to  resolver  and  cause  it  to  cache  incorrect  data  for  a  site  

•  Future  requests  (e.g.  from  any  of  the  ISP’s  users)  for  that  par>cular  site  would  lead  to  aCacker’s  bogus  web  site  

hCp://securityaffairs.co/wordpress/28283/cyber-­‐crime/dns-­‐cache-­‐poisoning-­‐emails.html  

What  is  DNSSEC  

•  It  uses  Public  Key  Cryptography  and  digital  signatures  to:  – Authen>cate  response  (the  sender  is  genuine)  – Ensure  Data  integrity  (you  receive  what  was  sent)  

•  It  does  not:  – Provide  confiden>ality  (response  is  not  encrypted)  – Prevent  DOS  aCacks  on  nameservers  

Public  Key  Encryp>on  

•  Sender  (nameserver)  hashes  response  message    and  encrypts  with  a  private  key.  This  is  returned  along  with  response  message  (retrieved  record)  

•  Receiver  uses  sender’s  public  key  to  decipher  encrypted  message.  –  If  unsuccessful  then  sender  is  fake  –  If  successful  then  compare  with  hashed  version  of  clear  response.    

–  If  comparison  unsuccessful  then  response  was  modified  

Chain  of  Trust  

•  How  does  receiver  know  that  the  public  key  is  correct  (there  is  no  cer>fica>on  authority  (CA)  as  for  SSL)?  

•  This  informa>on  is  passed  along  by  a  trusted  party  as  explained  next  

Simplified  Example  with  DNSSEC  

1)  Resolve  www.gov.C  

Root  

ripe.nic.C  

dns5.gov.C  

2)  www.gov.C?  

3)  .C  nameservers  &  PK  info  for  .C  

6)  www.gov.C?  

4)  www.gov.C?  

5)  gov.C  nameservers  &  PK  info  for  gov.C  

7)  190.213.5.230  

8)  190.213.5.230  

DNSSEC  resolver  

DNSSEC  client  

Experimental -- Internal experimentation announced or observed (11): CI GA GY HK HT IQ IR MS MU RW TOAnnounced -- Public commitment to deploy (11): DZ GH IE IL IT MX NO SG UY VN ZAPartial -- Zone is signed but not in operation (no DS in root) (5): AU HU LR MA VCDS in Root -- Zone is signed and its DS has been published (29): AD AF AG AW BY BZ CC CN ES FO GI GL GN HR KE KG KI LA LB LC MM NC NU PE PW

SJ TN TV UGOperational -- Accepting signed delegations and DS in root (62): AC AM AT BE BG BR CA CH CL CO CR CX CZ DE DK EE FI FR GR GS HN IN IO IS JP

KR LI LK LT LU LV ME MN MY NA NF NL NZ PL PM PR PT RE RU SB SC SE SH SI SXTF TH TL TM TT TW TZ UA UK US WF YT

ccTLD DNSSEC Adoption as of 2014-10-14Experimental Announced Partial DS in Root Operational

Why  Deploy?  

•  Required  for  gTLDs  (e.g.  .bank)  •  Has  vendor  support  (ISC/BIND,  Microsoj)  •  New  differen>ator  for  ISPs  •  Increases  trust  in  e-­‐commerce,  Government  Services  and  banking  

•  Opportunity  for  new  security  products  development  

 

.C  is  signed  

Present  status:  •  Registries  (e.g.  .C)  and  Registrars  

–  TTNIC  ✔  

•  Registrants  (especially  local  companies  and  Government)  –  Only  one  sub-­‐domain  signed      

•  ISPs  –  Not  sure  of  plans  for  DNSSEC  resolvers  

•  End  Users  –  Sojware  must  include  DNSSEC  support  

Conclusions  

•  Although  .C  is  signed  it  is  impera>ve  that  sub-­‐domains  also  deploy  DNSSEC  

•  The  TTNIC  is  willing  to  work  with  companies  and  Government  agencies  to  get  this  done  

•  Thanks!