dnssec key management policy · 2010-07-28 · key management july 21, 2010 [email protected] 3...

DNSSECKeyManagement

PolicyEdwardLewis

Neustar

DNSSECJP!

July21,2010 [email protected]

Agenda

•  WhatisKeyManagement?•  WhyandWhereitfits?

•  KeyManagementindetail

•  Ourexperiencein"dotUS"and"dotBIZ"

July21,2010 [email protected] 2

KeyManagement


•  IlearnedalotbyreadingUSNISTdocuments–  IamnotsureifthesameexistinJapan

•  AreadinglistforKeyManagement&DNSSEC– hVp://csrc.nist.gov/publicaZons/PubsSPs.html– SP800‐57,alsoseeSP800‐53,SP800‐81

•  HelpfulinformaZononHSMdevices– hVp://csrc.nist.gov/publicaZons/PubsFIPS.html– FIPS140‐2

WhyManageKeys?

•  DNSSECuseskeystoproducedigitalsignatures•  Keysareusedindifferentways

•  Keyshave"lifeZmes"andcannotbeconsideredtobe"forever"

•  Thereisalotofdebateonhowlongtouseakeyandhowakeyshouldbeused


電子署名の概念


公開鍵

秘密鍵

鍵生成

ランダム番号ジェネレータ

署名生成署名検証

秘密鍵

平文

公開鍵

平文

ハッシュ関数ハッシュ関数

平文

電子署名電子署名

Thegreybox

•  Onthepreviousslideagrayboxgroups– 鍵生成

– 署名生成– ランダム番号ジェネレータ– ハッシュ関数

•  ThesefuncZonsmaybeinasodwarelibrary(likeOpenSSL)ormaybeinanHardwareSecurityModule(HSM)


3waysdatachangesinDNSSEC

•  Zonefile'sdatachanges(sameinDNS)– Newhosts/addresses/etc.

•  Signaturesexpire(newinDNSSEC)– DNSSECreliesonexpiraZonZmeforrevocaZon– Signatureshavetobe"refreshed"

•  Key/cryptographicmaterialchanges(alsonew)– Keysandalgorithmsdon'tlastforever– RecoveryfromanaVackmayrequirenewkeys


HSMDNSSECFlow


鍵生成

署名生成

鍵キャッシュDNSSEC署名手順

DNSSECの鍵管理

DNSゾーンデータベース

DNSSECの署名の管理

ネームサーバ

ランダム番号ジェネレータ

秘密鍵

公開鍵

HSM&DNSSEC署名手順

•  HSMorsodwarecryptographiclibrary– Providesthe"mathemaZcmuscle"forcryptography

–  (non‐HSM:Openssllibraries)

•  DNSSEC署名手順signscurrentdatawithcurrentkeys– PutsthecryptographyintoDNSSECrecords,zones– Feedsthenameserver


WhenandHow(toSign)Policy

•  Decisionofwhentosignisgovernedby– DNSゾーンデータベースbecausedataischanged

– DNSSECの署名の管理becausesignaturesareexpiring(orwall‐clockalarmstrikes)

•  Decisionofwhatkeytouseisgovernedby– DNSSECの鍵管理hastomanagethecurrentsetandchangestothenextsetofkeys


PleaseRecycle

•  Regarding"whentosign"– GeneraZngnewsignaturesbeforeitisnecessarytodosoisdiscouraged

– ZonetransfersbecomelargeandnameserverssZllarenotgoodatjugglingzonetransfersandqueries

•  IfazoneisstaZc,letsignatureslivelongandrefreshthemwithshortoverlaps


DNSゾーンデータベース

•  ChangestothezonecontentswillcauseDNSSECsigningtohappen– Userchangestothezone(newhost)– DNSSECの鍵管理deliversanew公開鍵–  (Notshown)NSEC3parameterischanged

•  Policy– Azonemustalwayshaveacompletesetoffreshsignatures.NoexcepZons!


DNSSECの署名の管理

•  DNSSECsignatureshaveexpiraZonZmes– Whenasignatureexpiresitmustberefreshed

– UsuallythisfuncZonisbuiltintoothertools•  Policy– Ruleofthumb,refreshsignaturewellbeforeexpiraZontogiveenoughZmeto"recover"fromafailure


DNSSECの鍵管理

•  DeterminesiftheexisZngkeysare"good"orifthereisaneedtochange

•  KeyManagementPolicy– Followingslides

•  PolicyimplementaZon– Requiresnewkeypairstobegenerated– SendsDNSゾーンデータベースnewpublickeys– Rotateskeysintoandoutofservice– Revokeskeys


KeyManagementPolicyAspects

•  Keyroles– UseKSK/ZSKornot?FollowRFC5011?

•  Keyalgorithm(andhash)andsize– RSASHA256?SHA1?SHA512?GOST?– 1024bitsor2048bits?

•  KeylifeZme– DuraZonofkey"effecZvity"period– ProcedureandZmingofkeychange


KeyRoles

•  ChooseKSK/ZSKorjustonekey?–  Iftheparentzoneisfastandresponsive,onekeyisgood

– Butiftheparentisslow,theKSK/ZSKapproachisworththemanagementoftheextrakey

•  KSK/ZSK– AssumedbyDNSSECearlyadopters,notarequirement

– SeeRFC4641July21,2010 [email protected] 16

KSK/ZSK


ParentZone子ゾーン.日本　DS1234582A057C8553....

ChildZone...子ゾーン.日本　DNSKEY257...;keyid=12345子ゾーン.日本 DNSKEY256...;keyid=32123子ゾーン.日本 RRSIGDNSKEY...;by12345

TheZSK

SingleKeyDNSSEC

•  Managing1keyissimplerthanmanaging2•  Butonlyifyouhavea"quick"relaZonshipwithyourparentzone– NeedtochangetheDSrecordeveryZmeyouchangethekeysigningthezone

– Or,ifyouneverchangekeys...•  SincetheinvenZonofEPP,thisisplausible– Youcantryit,butIsZllencourageKSK/ZSK


SingleKey"Chain"


ParentZone子ゾーン.日本　DS1234582A057C8553....

ChildZone...子ゾーン.日本　DNSKEY257...;keyid=12345子ゾーン.日本 RRSIGDNSKEY...;by12345

TheZSK

RFC5011

•  Managementoftrustanchors– AnewkeyhastobepresentforsomeZmetoverifyitisindeedanewkey

– ArevokedkeyismarkedandsignedforsomeZmetoverifythekeyisremoved

•  Intendedforusewheretheparentzoneisnotsignedorwon'tholdDSrecords


KeyAlgorithmandSize

•  DSA,RSA,RSA+NSEC3,GOST– SeehVp://www.iana.org/assignments/dns‐sec‐alg‐numbers/dns‐sec‐alg‐numbers.xhtml

•  HashfuncZon– SHA‐1,SHA‐256orsomethingelse?

– SHA‐1isconsideredtobe"old"butsZllinuse•  Size– Longerishardertobreak,slowertouse


TheHashFuncZon

•  SHA1– Publishedin1995– 160bits– Widespread,butgerngtobe"breakable"

•  SHA2(orSHA256orSHA512)– Publishedin2001– 224/256or384/512bits– Morebits,harderto"break"


IslongerbeVerandslower?

•  Alongerkeyisthoughttobe– harderto"crack"soitismoresecure

– hardertoprocesssoitislessefficient

•  Whatdocryptographersfeel?– DNSSECisusesasubsetofcryptographicfuncZons– Thereisn'tenoughuseofakeytocrackit,provideditisstrongenough(1024bits)

•  Frankly,noonehasenoughexperienceyet


KeyLifeZme

•  LifeZme,fromcreaZontodeleZon,comprises– KeyeffecZvityperiod,theduraZonakeyisusedcryptographically

– KeyDNSSEClifeZme,theduraZonsneededtopublishandremoveakey,DNSTTLplaysarole

– RFC5011impactsZmingtoallowdetecZonofkeychangesifthereisnoparentsigning


KeyeffecZvityperiod

•  Thereissomedebate– DNSSECdevelopersthoughtthatkeyshadtobechangedbecauseofcryptographicproperZes

– Cryptographershavesaid(opinion)thatkeyswillbegood"unZlbroken"(whichistrue)

–  InoperaZons,regularchangesaregoodbecause•  Brokenkeysmaynotbedetected•  Keyscannotberevoked(RFC5011isaspecialcase)•  OperaZonalscriptsneedtobeexercised


TTLimpacts

•  hVp://tools.iet.org/html/drad‐morris‐dnsop‐dnssec‐key‐Zming‐02

•  AssumeakeyiseffecZvefor3months

•  WhataboutDNSzoneandcachepropagaZon?– Anewkeyhastobepre‐publishedtoavoidacachewitha"newdatasignatureandoldkeys."

– AnoldkeyhastohandaroundunZlallofitssignaturesaregone


CacheImpact


Auth

NS

2日

0日

3日

1日

Cache

NS

Cache

NS

Cache

NS

公開鍵#2

公開鍵#1

公開鍵#1

公開鍵#1

Auth

NS

Cache

NS

Cache

NS

Cache

NS

公開鍵#2

公開鍵#1

公開鍵#2

公開鍵#1

Auth

NS

Cache

NS

Cache

NS

Cache

NS

公開鍵#2

公開鍵#2

公開鍵#2

公開鍵#1

Auth

NS

Cache

NS

Cache

NS

Cache

NS

公開鍵#2

公開鍵#2

公開鍵#2

公開鍵#2

DNSSECBasicDNSKEYcycle


t=0 t=1 t=2 t=3

•  t=0DNSKEYisaddedtozone•  unZlt=1Somecacheswillhavetheoldset

•  t=1AllcachesshouldhaveDNSKEY•  unZlt=2PrivatekeycanmakeRRSIG

•  t=2privatekeyreZred•  unZlt=3RRSIGsinCaches,DNSKEYneeded•  t=3DNSKEYisremovedfromzone

BINDkeymanagement

•  InBIND9.7thereisanewkeymangementfeature–  (P)ublishist=0–  (A)cZvateist=1–  (I)nacZvateist=2–  (D)eleteist=3


ExperienceinUSandBIZ

•  USsignedinDecember2009,openforDSrecordsinJune2010

•  BIZbegansigningJuly2010

•  BothzonesareusingNSECbecausethereisnoreasontouseNSEC3– ZonescanberetrievedviaFTP– Wearen'tconcernedaboutsize


MypersonalTLDsurvey

•  IhaveascriptthatasksforDNSKEYfromthedelegaZonsintherootandinARPA– Skewedbytestzonesintheroot– ARPAincludese164.ARPAandothersignedzones

•  AsofearlyJuly,24"real"TLDsaresigned–  Iusethisonlyforsanitychecking,notreliableasameasureofoverallDNSSECadopZon

– Youwillseereferenceto"41"‐thatincludestestzonesandARPAzones


KeyRoles

•  WeuseKSK/ZSK– Becauseourparentisslow(theroot),noautomaZcupdateinterfaceandnoquickturnaround

– Weplantochangekeysfrequently

•  Survey,40outof41useKSK/ZSK– Butthatisn'tsurprisingasweallthinkalike

•  Singlekeyuse– Workablebutinmyopinion,nottooscaleable


KeyAlgorithm

•  Nocryptosystemisimposed(bylaw)sowechoosewhatseemsbest

•  Fromthe41signedzonesintherootplusARPAalluseRSA– 9zonesuseRSA‐SHA256,restuseRSA‐SHA1

•  RecommendaZon– Unlessyoumustuseanalgorithmforlegalreasons,chooseRSA‐SHA256

•  Don'tstartwithRSA‐SHA1(NSECorNSEC3!)July21,2010 [email protected] 33

KeySizes

•  WehavestucktothecommonwisdomofaKSKof2048andaZSKof1024bits

•  Survey"themostcommonsetup"


KeyLifeZme

•  KeyeffecZvity– 1KbitZSK‐3months

– 2KbitKSK‐1year•  Ourparameters– ZSKpublishedasaemergencykeyfor3months,signsfor3months

– KSKispublishedfor1yearastheemergencyand1yearastheacZve(DSatroot)

– TTLis6daysJuly21,2010 [email protected] 35

RFC5011support

•  WeplantosupportRFC5011– ButinrealitywecouldjustrelyontherootzonetohavetheDSrecord

– Asasafetymechanism,wepublishourkeysetonawebsite,soRFC5011supportisagoodthing

•  NoclearrecommendaZononRFC5011– Neededifparentisnotsigned– Probablynotifsigned


QuesZons

•  QuesZons?


dnssec key management policy · 2010-07-28 · key management july 21, 2010 [email protected] 3...

Documents