DKIMgmailsmtp

ALongitudinalandComprehensiveStudyoftheDANEEcosysteminEmailHyeonminLee,SeoulNationalUniversity;AnikethGireesh,AmritaVishwaVidyapeetham;RolandvanRijswijk-Deij,UniversityofTwente&NLnetLabs;Taekyoung"Ted"Kwon,SeoulNationalUniversity;TaejoongChung,RochesterInstituteofTechnologyhttps://www.
usenix.
org/conference/usenixsecurity20/presentation/lee-hyeonminALongitudinalandComprehensiveStudyoftheDANEEcosysteminEmailHyeonminLeeSeoulNationalUniversityAnikethGirishAmritaVishwaVidyapeethamRolandvanRijswijk-DeijUniversityofTwente&NLnetLabsTaekyoung"Ted"KwonSeoulNationalUniversityTaejoongChungRochesterInstituteofTechnologyAbstractTheDNS-basedAuthenticationofNamedEntities(DANE)standardallowsclientsandserverstoestablishaTLSconnec-tionwithoutrelyingontrustedthirdpartieslikeCAsbypub-lishingTLSArecords.
DANEusestheDomainNameSystemSecurityExtensions(DNSSEC)PKItoachieveintegrityandauthenticity.
However,DANEcanonlyworkcorrectlyifeachprincipalinitsPKIproperlyperformsitsduty:throughtheirDNSSEC-awareDNSservers,DANEservers(e.
g.
,SMTPservers)mustpublishtheirTLSArecords,whichareconsistentwiththeircerticates.
Similarly,DANEclients(e.
g.
,SMTPclients)mustverifytheDANEservers'TLSArecords,whicharealsousedtovalidatethefetchedcerticates.
DANEisrapidlygainingpopularityintheemailecosystem,tohelpimprovetransportsecuritybetweenmailservers.
YetitssecuritybenetshingeondeployingDANEcorrectly.
Inthispaperweperformalarge-scale,longitudinal,andcompre-hensivemeasurementstudyonhowwelltheDANEstandardanditsrelevantprotocolsaredeployedandmanaged.
Wecol-lectdataforallsecond-leveldomainsunderthe.
com,.
net,.
org,.
nl,and.
seTLDsoveraperiodof24monthstoana-lyzeserver-sidedeploymentandmanagement.
Toanalysetheclient-sidedeploymentandmanagement,weinvestigate29popularemailserviceproviders,andfourpopularMTAandtenDNSsoftwareprograms.
OurstudyrevealspervasivemismanagementintheDANEecosystem.
Forinstance,wefoundthat36%ofTLSArecordscannotbevalidatedduetomissingorincorrectDNSSECrecords,and14.
17%ofthemareinconsistentwiththeircerticates.
WealsofoundthatonlyfouremailserviceproviderssupportDANEforbothoutgoingandincomingemails,buttwoofthemhavedrawbacksofnotcheckingtheCertificateUsageinTLSArecords.
Onthebrightside,theadministratorsofemailserverscanleverageopensourceMTAandDNSprogramstosupportDANEcorrectly.
ThisworkwasdonewhiletheauthorsdidaninternshipatRochesterInstituteofTechnology.
1IntroductionTransportLayerSecurity(TLS)isresponsibleforsecuringIn-ternettrafcinavarietyofprotocolssuchasDNSandHTTP.
CoupledwithaPublicKeyInfrastructure(PKI),TLSreliesoncerticatestobindentitiestotheirpublickeys.
CerticatesaretypicallyissuedbyCerticateAuthorities(CAs),inahi-erarchicalfashion.
Atthetoplevelofthehierarchy,therearerootCAs,whohaveself-signedcerticatessincetheycannotrelyonothertrustedthirdparties.
However,thecurrentPKImodel,discussedabove,hasbeencriticizedforitspotentialvulnerability,sinceanyCAcanis-suecerticatesforanydomainname.
Historically,wehaveobservedthatcompromisedCAsissuedvalid-lookingbutfraudulentcerticatesinappropriately[15,58,75].
Sincethen,anumberofnewprotocolsandextensions[40,41,48,62,68]havebeenproposedtomitigatetheseproblems.
However,noneofthesefundamentallysolvestheproblem:thevalida-tionprocessofacerticatestillreliesonCAs.
Toaddressthisissue,theDNS-basedAuthenticationofNamedEntities(DANE)protocol[38]wasproposedtosup-portTLSwithoutrelyingontrustedthird-partieslikeCAs.
Atitscore,adomainnameownerthatrunsaTLSserversuchasHTTPS,orsecureemailviaSMTP+STARTTLS,canpublishitscerticateinformationasaDNSrecordcalledtheTLSArecord,whichcanbeusedbyTLSclientstoverifytheauthen-ticityofthecerticateinanon-PKIfashion.
Furthermore,theintegrityandauthenticityoftheTLSArecordsareguaranteedbytheDNSSecurityExtensions(DNSSEC)[16–18].
Thus,aTLSservercaneasilypublishandserveitscerticatewithoutrelyingonCAs,andTLSclientscanalsoverifythecerti-cateby(1)fetchingTLSArecords,(2)validatingthemusingDNSSECsignatures,and(3)checkingiftheTLSArecordsareconsistentwiththecerticatefromtheTLSserver.
Duetoitssimplebutrobustsecurityguarantees,therehavebeenanumberofattemptstodeployDANEfortheWebPKI(HTTPS).
However,DANEhasneverbeenadoptedduetotwooperationalchallenges.
First,aclient(i.
e.
,browser)maybebehindamiddlebox,whichisnotoriousfordiscardingUSENIXAssociation29thUSENIXSecuritySymposium613TLSAorDNSSECrecords.
Second,thebrowserneedstomakeadditionalDNSqueriestoretrievetheTLSAandDNSSECrecords,whichincursadditionallatency.
Thus,modernwebbrowsersdonotusuallysupportDANE[47].
Fortunately,manyemailserviceprovidershavebeguntodeployDANEfortheirSMTPservicesasusersaretoleranttomillisecond-orderadditionaldelaysinsendingandreceiv-ingemails—moreover,DANEcansolvesecuritychallengesinSMTPnotsolvedsofar,suchasSTARTTLSdowngradeattacks[27]andreceiverauthentication[37].
Inresponsetoemergingthreatsinemailsecurity[30],theDutchandGermannationalgovernmentsrequireDANEsup-portfromvendorsinpublictenders[13,19]andcertainTLDregistries(e.
g.
,the.
seand.
nlregistries)haveemployednancialincentivesforregistrarsprovidingemailhostingser-vicestodeployDANE[59].
Finally,popularmailserviceprovidershavealsobeguntodeployDANE;Web.
de(oneofthelargestfreewebmailprovidersinGermany)supportsout-boundDANEsince2016[29],andComcast(oneofthelargestISPsintheUS)didthesamething[26]inAugust2017.
LikeotherPKIs,however,DANEcanonlyfunctioncorrectlywhenallprincipalsfullltheirresponsibilities:TLSserverspresentingcerticates,DNSserverspublishingTLSArecords,DNSclientsvalidatingDNSresponsesusingDNSSEC,andTLSclientsverifyingcerticatesusingTLSArecords.
Unfortunately,thecomplexityofDANEleadstomanyopportunitiesformismanagement.
Forinstance,ontheserverside,TLSArecordsmayhaveDNSSECerrorssuchasexpiredsignatures,orthecerticatesmaybeinconsistentwithpublishedTLSArecords.
Ontheclientside,DNSresolversmaynotvalidateTLSArecordsproperly,orbuggyTLSappli-cationsdonotbothertocheckthevalidityofcerticates.
SurprisinglylittleisknownaboutthepracticeofthecurrentDANEPKIecosystemforemailservices.
WhiletherehavebeensomestudiesofDANE[83],nopriorworkhasstudiedtheDANEPKIinSMTPlongitudinallyorcomprehensively.
Inthispaper,wepresentacomprehensivestudyoftheentireDANEecosystemforSMTP.
Tostudyserver-sidebe-havior,ourworkleveragesdailysnapshotsfor24monthsandhourlysnapshotsfor4monthsofMXrecordsandTLSArecordsforallsecondleveldomainnamesthatendwith.
com,.
net,.
org,.
nl,or.
se.
FortheMXrecordspresent,weretrievethecerticatesofthecorrespondingemailservers.
Tostudyclient-sidebehavior,weinvestigatehowDANEissupportedbyanalyzing(1)the29mostpopularemailserviceproviders,(2)theirDNSresolvers,(3)softwareimplementationsofpop-ularorDANE-supportingmailtransferagents(MTAs),and(4)softwareimplementationsofpopularDNSprograms.
Ouranalysisrevealsmanyinstancesoftroublingandper-sistentmismanagementintheDANEPKIinSMTP:First,wendnearly36%ofTLSArecordscannotbevali-datedduetomissingorincorrectDNSSECrecords,e.
g.
,some19%aresignedbutlackasecuredelegation(i.
e.
,DSrecords).
Second,eventhoughmostofthemailserversthatpro-videTLSArecords(99.
5%)presenttheircerticatesthroughSTARTTLS,wendthatover14%ofthemdonotmatchthepresentedcerticates.
Third,whenfocusingon29popularemailproviders,wendthatonlyfourofthemsupportDANEfortheiroutgoingandincomingemailsandoneprovideronlysupportsDANEforincomingemails.
Finally,wetestedfourpopularMTAandtenpopularDNSimplementationstoseeifemailproviderscaneasilysupportDANE;wendthattwopopularMTAscorrectlysupportDANEforbothincomingandoutgoingemailsinconjunc-tionwithfourDNSimplementationsthatsupportTLSArecordsandDNSSEC.
Overall,ourresultsshowthatDANEdeploymentisrare,butsteadilyincreasing(especiallyinsomecountry-codeTLDs).
Unfortunately,wealsondwidespreadmismanage-mentofcerticatesandTLSArecords.
Onthebrightside,however,onlyafewplayerscaneasilymakechangesinordertobringthebenetsandagreateradoptionofDANEtoendusers,whicharemainlylargeemailprovidersandMTAandDNSSoftwareproviders.
Toallowotherresearchersandadministratorstoreproduceandextendourwork,wepubliclyreleaseallofouranalysiscodeanddatatotheresearchcommunityathttps://dane-study.
github.
io2BackgroundInthissection,weprovideanoverviewofDNS,DNSSEC,DANE,andexplainhowtheyworktogethertosecureemailtransport(i.
e.
,SMTP).
DNSandDNSSECDNSmaintainsthemappingbetweendomainnamesandtheirassociatedvaluessuchastheirIPv4addresses(Arecords)andtheirmailservers'domainnames(MXrecords).
Unfortunately,theoriginalDNSprotocol[55]hasserioussecurityproblems(e.
g.
,noauthenticationofDNSrecords),makingDNSvulnerabletonumerousattackssuchasDNShijackingandcachepoisoning[21,42,70].
Topre-ventsuchattacks,theDNSSecurityExtensions(commonlyreferredtoasDNSSEC)wereintroducedtoprovideintegrityandauthenticityofDNSrecordsusingthreenewrecordtypes:DNSKEYrecords,whichcontainpublickeysusedinDNSSEC.
RRSIGrecords,whichcontainthecryptographicsignatures(ofDNSrecords)generatedbytheprivatekeys;theircor-respondingpublickeysareinDNSKEYrecords.
DSrecords,whicharehashesofDNSKEYs.
TheserecordsmustbeuploadedtotheparentDNSzonetoconstructachainoftrust,whichreachesuptotherootDNSzone.
61429thUSENIXSecuritySymposiumUSENIXAssociationTLSARecordsDANEintroducesanadditionalDNSrecordtype,calledtheTLSArecord[38],whichprovidesinforma-tionthatcanverifythecerticateofacorrespondingdomainname.
TherecanbemultipleapplicationsthatrequireTLSforasingledomainname.
Thus,aTLSArecordisstoredforaparticularlocation,whichisacombinationofaportnumber,aprotocol(i.
e.
,TCPorUDP),andabasedomainname.
Foragivenbasedomainname,thisallowsspecicationofdifferentcerticatesfordifferentcombinations(i.
e.
,differentapplica-tions).
Forexample,torequestaTLSArecordforanSMTPserverthathasasitsMXrecordmail.
example.
comandsup-portsSTARTTLSonport25,thederiveddomainnamemustbe_25.
_tcp.
mail.
example.
comtofetchitsTLSArecord.
ATLSArecordconsistsoffourelds(detailsin[38]):CertificateUsage,whichspecieshowthepresentedcerticatesfromtheTLSservercanbevalidatedwiththeCertificateAssociationData(seebelow).
TherearefourCertificateUsages:rst,itcanspecifythatthecerticateforCertificateAssociationDatashouldbeusedaseither(a)atrustanchor(i.
e.
,arootcerticate),thuspermittinganyleafcerticatesaslongastheyaresignedbythetrustanchor(DANE-TA),or(b)aleafcerti-cate(DANE-EE),bothofwhichdonotrequireanyIETFPKIXvalidation.
Inotherwords,ifthepresentedcerticateofwhichCertificateUsageinthefetchedTLSArecordiseitherDANE-TAorDANE-EE,theTLSclientdoesnotneedtocheckifthecerticateissignedbytrustedCAsorisal-readyintherootcerticatestores.
Similarly,thePKIX-TAusagecanspecifythat(c)CertificateAssociationDatahastobeusedasatrustanchor,or(d)PKIX-EEforaleafcerticate.
NotethatthepresentedcerticatemustpassPKIXcerticationpathvalidationusingasetofrootcerticatestores,whicharemutuallyagreedbetweentheclientandtheserver.
Selector,whichspeciesthetypeofCertificateAssociationData,indicatingwhethertheCertificateAssociationDataisderivedfromacerticateoritssub-jectpublickey.
MatchingType,whichspecieswhatCertificateAssociationDatapresents,whichcanbetheoriginaldata,itsSHA-256hash,oritsSHA-512hash.
CertificateAssociationData,whichcontainsthefulldataoradigestofacerticateoritspublickey.
Atrstglance,itmayseemthatPKIX-TAorPKIX-EEwouldbemoresecureastheyrequireadditionalPKIXvali-dation;infact,theyonlyprovideillusoryincrementalsecu-rityoverDANE-TAorDANE-EE.
IfattackerscancompromisetheintegrityofDNSSEC,PKIX-TAorPKIX-EEcanbeeas-ilyreplacedbyforgedTLSArecordscontainingDANE-TAorDANE-EE,sothatanyaddedPKIXvericationcanbeby-passed.
Moreover,theyareevenmorebrittleinSMTPwithSTARTTLSsincetheTLSclientandTLSserverneedtohavealistofmutuallytrustedCAandTLSservers,whichstillreliesontrustedthirdparties(i.
e.
,CAs)tomanagetheircer-ticates.
Thus,theDANEoperationalpracticerecommendstoavoidusingPKIX-EEandPKIX-TA[28].
DANEandDNSSECATLSclientmaybevulnerabletoman-in-the-middle(MITM)attacksifitcannotverifytheserver'scerticatethatbindsapublickeytotheserver'sidentitysuchasthedomainnameofthemailorwebserver.
Inanemailprotocol,however,thenameoftheemailserverisnotusuallyencodedintherecipientaddress;instead,theclientobtainstheservernamethroughanMXrecordlookup1.
ToleverageDANE,theclienthastoobtainTLSArecordstoverifythepresentedcerticatefromaTLSserver.
However,ifthereisnosecurityguaranteethatthefetchedDNSrecords(includingTLSA)arenotauthentic,theclientcanbevulnera-bletoactiveattackssuchasMITMandDNScachepoisoning.
Thus,aclientwhowishestorelyonDANEmustuseDNSresolversthatsupportDNSSEC,oritneedstolookupandauthenticatetheDNSrecordsusingDNSSECbyitself.
DANEandSMTPEmailserviceprovidersuseSMTP(asTLSclients)tosendemailstodestinationmailservers(i.
e.
,TLSservers).
However,SMTPhasnobuilt-insecuritymechanismssuchasauthenticatingrecipientsorencryptingmessagesintransit.
Toovercomethislimitation,anSMTPex-tensioncalledSTARTTLSwasintroducedin2002toencryptthemessageswithinaTLSsession[37].
However,unlikeotherTLSprotocols,suchasHTTPSthatsignalsTLSsup-portexplicitlythroughtheURIscheme(e.
g.
,https://),anemailaddressitselfcannotindicateanytransportsecuritypol-icy.
Thus,STARTTLSsupportsopportunisticTLS;aclientcansendaplain-textcommand,"STARTTLS",toexpressitsTLSsupportattheinitialstageoftheSMTPconnection.
Un-fortunately,STARTTLSiswell-knowntobevulnerabletodowngradeattacks,inwhichaman-in-the-middlemaystripouttheSTARTTLScommand.
Evenworse,theSTARTTLSRFC[37]doesnotspecifywhattodowhenthecerticatepre-sentedbytheTLSserverisnotvalid,thusmakingmanyTLSclientsignoremismatchesbetweenMXrecordsandthedomainnamesinthecerticatesorcontinueemailtransmissionsevenwithinvalidcerticates(e.
g.
,self-signedcerticates)[30].
WithDANE,however,thedestinationmailservercanex-plicitlytelltheclientsthroughTLSArecordsthat(1)itsup-portsTLSforsecureemailtransmissions,(2)thepresentedcerticatewillbeexactlymatchedwiththeTLSArecords,and(3)theTLSArecordsarenotforgedbyprovidingtheirRRSIGs,DNSKEYs,andDSrecords.
Figure1brieyillustrateshowanSMTPclientcanuseDNSSECtoverifytheintegrityandauthenticityofthefetchedTLSArecordsandvalidatethecerticates.
1Forexample,adomainname(oftheemailserver)mappedtoarecipientaddressofuser@gmail.
comisgmail-smtp-in.
l.
google.
com,whichisspeciedintheMXrecord.
USENIXAssociation29thUSENIXSecuritySymposium615Figure1:OverviewofhowDANEworksalongwithDNSSECandSTARTTLS.
TheintegrityandauthenticityofTLSArecordsaresupportedthroughDNSSECchainvalidation;EachRRSIGisthesignatureofarecordset(e.
g.
,TLSArecords)veriedwithaDNSKEY(bluelines)andeachDSrecordisuploadedbyachildzone(redlines).
AfterDNSSECchainverication,theSMTPclientveriestheobtainedcerticatebymatchingwithittoaTLSArecord.
3RelatedWorkInthissection,wediscussrelatedworkconcerningstudiesoftheDANEecosystemandsecurityprotocolsforemail.
DANEDeploymentLiangetal.
[83]studiedtheearlystagesofDANEdeploymentin2014.
Theyspecicallyfo-cusedontheveryearlystageofDANEusagefortheHTTPS,SMTP,andXMPPprotocols.
Liangetal.
foundfewerthan1,000TLSArecordsin485Ksignedzones,ofwhich13%wereinvalid,whichindicatedthatDANEusagewasveryrare.
TherehavebeenmanyattemptstodeployDANEtoWebPKIinbrowsers[47,72];however,duetosomeproblemslikemiddleboxesblockingTLSArecordslookup,thesewereabandoned.
Recently,anewTLSextension[56]proposestoallowawebservertodeliveritsDANErecordsanditsDNSSECauthenticationchainduringTLShandshakes.
Thisextension,however,hasnotbeenstandardizedyet.
Dukhovnietal.
publishDANEdeploymentstatisticspe-riodically[34,77];theyrecentlyfoundthat1.
4MdomainspublishsignedMXrecordsthathaveTLSArecords.
Web-baseddebuggingtoolssuchasDANESMTPValidator[32]andDANECheck[25]canhelpadministratorsverifycorrectDANEdeployment.
Ourstudyextendsthesepriorstudiesinthreeways.
First,weexamineallTLSArecordsinthreeofthelargestgTLDsandtwoccTLDswiththehighestDNSSECdeploy-mentratesfor24monthstoinvestigatethestatusofDANEdeploymentlongitudinally.
Second,weprimarilyfocusonhowrecentincentivesforDANEdeployment[13,19,59]haveimpactedonthedynamicsofDANEecosystem;thisisincon-trasttotheearlierworkin2014[83]thatfocusedontheveryearlystageofDANEdeploymentwherenobodyreliedonDANEproductionsystems.
Sincethen,therehavebeenmul-tipleincentivesintroducedbynationalgovernments[13,19]andTLDregistries[59]tospurgreateradoptionofDANE,whichcompletelychangedthelandscapeofDANE;forexam-ple,theGermanandDutchnationalgovernmentguidelinesforsecureemailsstatethatDANEismandatoryforgovern-mentbodiesandonthecomply-or-explainlistforpublicten-ders[13,19]andweconrma1,400-foldand3,100-foldincreaseofDANEusagesin.
comand.
netdomainscom-paredtoearlierwork[83],whichwedetailinthefollowingsection.
Third,weexamineDANEdeploymentmorecompre-hensivelyincludingTLSAvalidationagainsttheircorrespond-ingcerticatesand(mis)congurationsoftherelatedentities(e.
g.
,SMTPserversandclients)tostudythecompleteDANEecosysteminemail.
EmailSecuritySMTPhaslongbeenfraughtwithsecu-rityissuessuchassenderspoong[36,66].
Toaddresstheseproblems,therehavebeenmanySMTPextensionssuchasDomainKeysIdentiedMail(DKIM)[20],theSenderPol-icyFramework(SPF)[45]andDomain-basedMessageAu-thentication,Reporting,andConformance(DMARC)[44].
Theirpurposesaremainlytoauthenticateasenderandver-ifytheintegrityofreceivedemails,butnottoencryptemailtransport.
Studieshavefocusedonhowmanyemailserverssupportthoseextensions[30]orhowpopularemailserviceprovidersactuallybehave[36].
Toencryptemails,START-TLS[37]wasintroducedin2002andseveralstudiesfocusedonthedeploymentofSTARTTLS[30,35,57,74].
Forexample,Fosteretal.
[35]showedthat89%ofpopularemailserviceprovidersdeployedSTARTTLS.
Similarly,Rijsetal.
[69]alsoshowedthat60.
3%of116scanneddomainsmainlyfromtheNetherlandssupportSTARTTLS.
However,STARTTLSwasoriginallydesignedtoprotectmessagesfrompassiveeavesdroppers,thusoneoftheremainingchallengeswasthelackofanauthenticationmechanismofreceivermailservers.
Durumericetal.
[30]showedthat52%ofSMTPserversinAlexa1Mdomainspresentedtrustedcerticates,and34.
2%oftheirCommonNamevaluesareconsistentwiththeonesintheirMXrecords.
Recently,MTA-STSwasproposedtoauthenticateemailserversandresistSMTPdowngradeattacks[53].
EventhoughMTA-STSissimpletodeploywithaTXTrecord,itdoesnotprovideanysecurityguaranteeforcerticatesandtheintegrityoftherecord(e.
g.
,MITMattackcantakeplacebysimplydroppingtheTXTrecord).
Also,MTA-STSreliesontrust-on-rst-use(ToFU)andpolicycaching.
Thus,theinitialSMTPconnectionistrustedwithoutauthenticationofthereceivingmailserver[53].
4DANEDeploymentWestudytheDANEPKIinemailapplicationswithafocusonitsdeploymentbyanalyzinghowemailserversconguretheir61629thUSENIXSecuritySymposiumUSENIXAssociationTLDMeasurementPeriodMXRecordsNumberPercentwithTLSA.
com2017-10-22–2019-10-3172,981,4650.
7%.
net2017-10-22–2019-10-317,440,4887.
3%.
org2017-10-22–2019-10-316,112,0577.
0%.
nl2017-10-22–2019-10-314,369,3439.
8%.
se2017-10-22–2019-10-31860,41338.
2%Table1:OverviewoftheDailydatasetsforthisstudy.
ThenumberandpercentageofthedomainsthathaveTLSArecordsareas-ofOctober31,2019.
MXrecordsandthecorrespondingTLSArecords.
Inparticular,wecarryoutalongitudinalstudytoseehowtheemailservershavechangedtheirMXandTLSArecordsovertime.
Letusrstintroducethedatasetsofourstudy.
4.
1DatasetsOurgoalinthissectionistoconductalargescaleandlongitu-dinalmeasurementstudyofDANEdeploymentintheemailecosystembyfocusingontheirauthoritativeDNSservers.
DailyScans:MXandTLSArecordsWeutilisedatafromtheOpenINTEL[60,80]measurementplatformthatfetchesDNSrecordsforallregistereddomainsinmanyTLDs,cur-rentlycoveringaround65%oftheglobalnamespace.
Forourstudy,weselectthedataforthreegenericTLDs(.
com,.
netand.
org)andtwocountrycodeTLDs(.
nland.
se);wendthatthereare178MresolvabledomainsinthedatasetfortheseTLDs.
Wechoosethe.
com,.
net,and.
orgTLDsbecausetheyarethethreelargestTLDs,and.
nland.
sebecausethesecountriesshowhighratesoftheDNSSECde-ployment[33],whichisessentialforDANE.
Foreachdomain,werstextractSOAandDNSKEYrecordswiththecorrespond-ingRRSIGrecords,andMXrecords.
Afterthat,weconstructadomainnametoqueryTLSArecordsbasedoneachMXrecord2.
Thedailysnapshotswerefetchedfor24monthsbetweenOc-tober22,2017andOctober31,2019.
Table1summarizesthisdataset.
Takentogether,thedailyscansrepresentoneofthemostcomprehensivedatasetsofDANEobservations.
4.
2DANEprevalenceWebeginbyexamininghowDANEhasbeendeployedbyemailserversbyfocusingonthenumberofsecond-leveldo-mainsthatserveatleastoneTLSArecordfortheirMXrecords.
Figure2plotsthefractionsof.
com,.
net,.
org,.
nl,and.
sesecond-leveldomainsthatpublishatleastoneTLSArecordfortheirMXrecords.
WerstnoticethatDANEdeploymentforMXrecordsisveryrareingTLDs:onlybetween0.
6%(.
com)2BecausetheSMTPprotocolcanusethreepossibleportnumbers(25,465,and587),wesendthreeTLSArecordrequestsforeachMXrecord.
Figure2:ThepercentagesofdomainswithMXrecordsin.
com,.
org,.
net,.
nl,and.
sedomainsthathaveTLSArecordsfromtheDailydatasetareshown.
0.
60%(.
com)0.
73%(.
net)ofalldomainswithMXrecordshavecorrespondingTLSArecordsinthelatestsnapshot.
and0.
73%(.
org)haveTLSArecordsfortheirMXrecords.
However,wealsomakethefollowingobservations:First,weseethatthefractionofMXrecordswithTLSArecordsissteadilygrowing.
Forexample,thefractionin.
comrosefrom0.
10%inOctober2017to0.
65%inOctober2019showingmorethan400KMXrecordshaveaccompanyingTLSArecords.
Second,wenoticethatwhiletheoverallDANEdeploymentrateinthethreegTLDsisquitelow,thedeploymentrateismuchhigherin.
nland.
se.
Recentstudies[23,49]reportedasimilartrendforDNSSECdeploymentinthesetwoccTLDs,duetothenancialincentivesfromtheregistries.
Third,weobservethatthegrowthinDANEdeploymentismainlyduetothefactthatasmallnumberofemailserviceprovidersprovideemailhostingservicesleveragingTLSArecordssuchasone.
comandLoopia.
Thatis,wendthatthe"spikes"weobserveinuptakeareduetosomepopularemailserviceprovidersthatprovideemailhostingservicestomanydomains.
Forexample,thespikeonNovember23,2018wasduetoasinglehostingprovider(one.
com)publishingasingleTLSArecord,whichimpacted934,066domainsthatpointedtheirMXrecordstoone.
comtooutsourcetheiremailservices.
3Similarly,Loopia(aSwedishserviceprovider)publishedTLSArecordsfortheirMXrecords,whichresultedinDANEdeploymentforits76,776domainsinstantlyinSeptember2019.
However,wearealsoabletoobservedropsinAugust2019,whichwerecausedbyone.
comthatremoveditsTLSArecordsforsomeMXrecordsmaking12,658.
com,.
net,and.
orgdomainstemporarilyforgotheirTLSArecords.
3Thisspikeisnotacoincidence;oneofourco-authorspresentedonDANEtotheoperatorcommunitytwodaysbeforethisspike,andweknowfromprivatecommunicationthisinuencedthedecisionofone.
comtoenableDANE.
USENIXAssociation29thUSENIXSecuritySymposium617Figure3:ThepercentagesofdomainspublishingbothMXandTLSArecordsasafunctionofwebsitepopularityareshown.
MorepopularwebsitesaremoreinclinedtodeployDANEfortheiremailservices.
ThischangewasrevertedinSeptember2019.
Wesuspectthatone.
commigratedthesedomainstootherMXrecords.
ThisobservationsuggeststhatemailhostingservicesplayasignicantroleinDANEdeploymentforSMTP.
Next,weexaminewhetherpopulardomainsaremorelikelytodeployDANE.
Figure3showsthepercentageoftheMXrecordsintheAlexatop1Mdomainsin.
com,.
net,.
org,.
nl,and.
sethatpublishTLSArecords,asofOctober31,2019.
WerstobservethatpopularwebsitesaremorelikelytohaveTLSArecordstosupportDANE,buttheoverallDANEde-ploymentremainslowevenamongthemostpopulardomains;forexample,theaveragepercentageofdomainswithTLSArecordsamongthetop100,000populardomainsis0.
45%,whilethatofthebottom100,000populardomainsis0.
21%.
However,wecannotknowifallofthesedomainscorrectlydeployedDANEonlybyanalyzingTLSArecords.
Wehavetocheck(1)iftheirTLSArecordsarecorrectlysigned,(2)iftheysupportSTARTTLStopresenttheircerticates,and(3)ifthecerticatesareconsistentwiththecorrespondingTLSArecords.
Thus,weperformamoredetailedexaminationofwhethertheyoperateDANEcorrectlyinthefollowingsections.
4.
3SecurityconsiderationsWebeganbyfocusingonthesecond-leveldomainsthatserveatleastoneTLSArecordfortheirMXrecords.
However,giventhatdomainscanservemultipleMXrecordsforbetteravailabil-ity,itisidealtodeployTLSArecordsforalloftheirMXrecordstostopactiveattackerswhointentionallyattempttodisruptanSMTPconnectiontothemailserverswithTLSArecordsandsteeravictimSMTPclienttowardsthemailserversthatarenotequippedwithTLSArecords.
WenowtrytounderstandifdomainshavefullydeployedDANEbyinvestigatingthenumberofdomainsthathavedeployedTLSArecordsforalloftheirMXrecords.
Figure4showstheratioofdomainsthatfullydeployedTLSArecordsandwemakeanumberofobservations.
First,wefoundthatasubstantialportionofdomainsfromFigure4:ThepercentageofdomainswithatleastoneTLSArecordthatalsofullydeployedTLSArecordsforalloftheirMXrecords.
.
com,.
net,.
org,and.
nlpartiallydeployedTLSArecords;onaverage18%of.
com,.
net,.
organd39%of.
nldo-mainsdidnotfullydeployTLSArecordsinouroldestsnap-shot,whichimpliesthatthesedomainsweresusceptibletodowngradeattacks.
Thefractionofthesedomainsis,however,steadilydecreasing;forexample,inthelatestsnapshot,wefoundonlylessthan5%of.
com,.
net,and.
orgdomainspartiallydeployedTLSArecordsand15%of.
nldomainsdidso.
Second,weobservethatlargeemailproviders(one.
comandloopia.
se)partiallydeployedtheirTLSArecordsrstandintroducedDANEforalloftheirMXrecordsafewdayslater;forexample,ittooktwodaysforone.
comtofullyde-ployTLSArecords.
Webelievethistobeanintentionalactiontominimizetheriskofpotentialmistakesduringthedeploy-mentandcongurationoftheTLSArecords.
5DANEManagementRecallthatproperlymanagingDANEforemailsmeansthatadomainownermust(1)enableDNSSECcorrectlybypub-lishingDNSKEYandRRSIGrecords,anduploadingaDSrecordintheTLDzone,(2)publishaTLSArecord,and(3)supportSTARTTLSandserveacerticatethatcanbeveriedusingitsTLSArecord.
Thus,wenowinvestigatewhetherdomainswithMXandTLSArecordstakeallthenecessarystepstosup-portDANEcorrectly.
5.
1DatasetOurgoalinthissectionistounderstandhowdomains(i.
e.
,emailservers)withMXandTLSArecordsdeployandoperateDANEcorrectly.
TheDailydatasetsufcesforstudyingthedeploymentofTLSArecordsintheSMTPprotocolatacoarsegranularity.
However,itdoesnottelluswhethertheemailserverspresenttheircerticates,andwhetherthecerticates61829thUSENIXSecuritySymposiumUSENIXAssociationVantagePointMeasurementPeriodThenumberofTLSACertsOregon11,82110,526Virginia2019-07-1111,80610,521SoPaulothrough11,77110,470Paris2019-10-3111,81910,531Sydney11,77010,484Table2:OverviewoftheHourlydatasets.
Thenumberofthecol-lectedTLSArecordsandthecerticatesareas-ofthelastsnapshotonOctober31,2019.
areactuallyconsistentwiththeTLSArecords.
Thus,wealsocollect(1)allthecerticatespresentedbytheemailserversindicatedintheMXrecords,and(2)thecorrespondingTLSArecords,toobservedynamicsatthetimescaleofhours.
Hourlyscans:certicatesandTLSArecordsThefollow-ingstepsdetailourmethodologytoobtaincerticatesfromthemailserversthatpublishTLSArecords.
1.
WerstobtainalltheMXandTLSArecordsfromourDailydataset,whichareupdatedeveryday.
2.
WedevelopedameasurementSMTPclientthatinitiatesanSMTPconnectiontoanemailserver(thatcorrespondstoeachMXrecord)througheachoftheSMTPportnumbers(i.
e.
,25,465,and587).
TheclientthensendstheSTARTTLScommandtoupgradetheSMTPconnectiontoTLS,andfetchesthecerticateeveryhour.
3.
WealsocollectandvalidateTLSArecordsintermsofDNSSECeveryhour.
4.
WedeploythemeasurementSMTPclientinvedifferentvantagepointsaroundtheworld—Oregon(AmazonWebServices[AWS]U.
S.
West),Virginia(AWSU.
S.
East),SoPaulo(AWSBrazil),Paris(AWSFrance),andSydney(AWSAustralia)—tocomprehensivelyunderstandhowemailserversandtheirDNSserversbehave.
Allmeasure-mentclientsareperfectlysynchronizedtominimizedis-crepanciesbetweenDNSrecordsandcerticatesacrossthevantagepoints.
4Weusedtheabovemethodologytogathermeasurementsbysendingonaverage11,972TLSArecordlookupsaswellascollectingthecerticatechainseveryhourfromJuly11,2019toOctober31,2019.
WerefertothesemeasurementsastheHourlydatasetandTable2summarizesthisdataset.
EthicalConsiderationsOurprimaryethicalconcernistominimizethepotentialperformancerisksassociatedwithtargetemailserversbyestablishingSTARTTLSconnectionseveryhour.
Firstofall,wehavenotsentanyemailstothe4Measurementcompletiontimesmaydifferdependingonthevantagepoint.
Theaveragedifferencebetweenthefastestandslowestvantagepointisonly13.
9seconds.
ItispossiblethattwovantagepointsmayfetchtwodifferentTLSArecordsifarolloveroccursexactlybetweenthetwoscans,butwebelievethistobeveryunlikely.
Figure5:ThepercentageofsignedTLSArecords(top)andthepercentageofthemmissingDSrecords(bottom)fromtheHourlydatasetareplotted.
About80%ofTLSArecordsaresigned,but20%ofthemstillmissDSrecordsinthelatestsnapshot.
emailservers.
Wehaveonlycollectedthepresentedcerti-catesfromtheemailserversaftersendingSTARTTLScom-mands.
WealsoregisteredaPTRrecord5foreachofthevemeasurementclients,whichindicatesadomainthatrunsawebpageexplainingthepurposeofourmeasurementsandin-structionsfortheDNSandSMTPoperatorsonhowtooptout.
Duringthefourmonthmeasurementperiod,wereceivedtenopt-outrequestsandexcludedtheirdomainsandIPaddressesfromthemeasurement.
5.
2MissingComponentsWenowexaminewhetherdomainsthatpublishTLSArecordsalso(1)publishallthenecessaryDNSSECrecordsand(2)supportSTARTTLS.
DNSSECRecallfromsection2thatadomainthatpublishesTLSArecordsmustproperlydeployDNSSEC;TLSArecordsmustbesignedbyitsprivatekey,whichcorrespondstothepublickeyintheDNSKEYrecord,andhaveaDSrecordintheparentDNSzonetocreateachainoftrust.
WerstfocusontheTLSArecordspublishedbyadomainthatattemptstodeployDNSSECforDANEbygeneratingRRSIGsusingtheirDNSKEYs;consistentwithpriorwork[50,79],werefertotheserecordsassignedrecords.
WebeginbyexaminingthepercentageofsignedTLSArecordsusingtheHourlydataset(topofFigure5).
AkeyobservationisthatDNSSECdeploymentforTLSArecordsispervasive,showingthat80%ofTLSArecordsaresigned.
Next,weseehowmanysignedTLSArecordsdonothavecorrespondingDSrecords;Figure5(bottom)showstheper-centageofsignedTLSArecordsthatcannotbevalidateddue5ThisDNSrecordisusedforthereverseDNSlookup;itmapstheassociateddomainorhostnamefortheIPaddress.
USENIXAssociation29thUSENIXSecuritySymposium619Figure6:ThepercentageoftheestablishedSMTPconnectionsthatfailtoinitiateTLSconnectionsisshown.
tomissingDSrecords.
Interestingly,weobservethat18.
5%ofthesignedTLSArecordsdonothaveDSrecords.
Thisissomewhatinlinewitharecentstudy[22],whichshowedthatabout30%ofsigneddomainsdonotuploadDSrecordsbe-causeofmismanagementbylargehostingserviceprovidersthatprovideauthoritativeDNSserversfortheircustomers.
ThismeansthattheemailserversthatusethoseTLSArecordsdonotprotfromanyofthesecuritybenetsthatDANEprovideseveniftheypresentcerticatesthroughSTART-TLS,whichareconsistentwiththeirTLSArecords.
ThisisbecauseDANE-supportingemailserversforoutgoingemailsshouldnotuseTLSArecordsthatcannotbevalidatedthroughDNSSEC.
InstallingDSrecordsintheparentzoneoftenre-quiresamanualprocesswherethedomainadministratortypi-callyneedstocontactitsregistrar.
ThuswebelievethattheCDNSKEYandCDSprotocols,whichallowthedomainownertodirectlyuploadtheDSrecordtotheregistrycouldmitigatethisoverhead[46,82].
STARTTLSNow,weturnourattentiontotheemailserversrunningontheMXrecords.
OurgoalistounderstandhowtheemailserverssupportSTARTTLStopresenttheircerticates.
RecallthatwesetupSMTPclientsfortestingpurposes.
Forthisgoal,werstregisterPTRrecordsfortheIPaddressesusedfortheSMTPclientstopreventourconnectionsfrombeingdeniedbytheemailservers;inthisway,eachSMTPclientcaninitiateanSMTPconnectionforeachemailserver.
However,whenweattempttomakeanSMTPconnection,wenoticethatonaveragesome20emailserversblockourcon-nectionsineachround.
EventhoughweregisterPTRrecordsinourDNSserverandsendnot-spamrequeststowell-knownblockremovalcenterssuchasSpamhaus[73],someemailserversstilldonotallowustoinitiateSMTPconnectionsbe-causeoftheircustomblocklists.
SMTPerrorcodesexplicitlyshowusthatourconnectionsarerejectedduetotheirspamlters.
WeidentifytheSTARTTLSrelatederrorsbypairingtheerrorcodesandmessagessuchas500indicatingthattheemailserverdoesnotunderstandthecommand,or502in-Figure7:ThepercentageofTLSArecordsthatareDNSSECinvaliddueto(1)wrongDNSSECcongurationssuchasexpiredRRSIGsand(2)TLSArecordsinconsistentwiththecerticates.
dicatingthatthe(STARTTLS)commandisnotimplemented.
WealsoconsidererrorsinnegotiatingTLSconnectionssuchasmalformedcerticatestructures,handshakefailures,andnocerticatessuggested.
Figure6plotsthefractionoftheestablishedSMTPconnectionsforwhichwecannotnegotiateSTARTTLSconnections;notethatonaverage0.
22%ofemailserversdonotimplementSTARTTLS,and0.
29%ofthosesupportingSTARTTLSprovidenoormalformedcerticates.
Takentogether,theseresultsshowthatthemajorityofthefail-ureofcorrectDANEdeploymentisduetomissingDSrecordsratherthanabsenceofSTARTTLSsupport;theaveragefailurerateoftheSMTPserversduetounimplementedSTARTTLSislessthan0.
2%,whilethefailurerateduetomissingDSrecordsis20%.
5.
3IncorrectComponentsProviding(i)asignedTLSArecordanditsDSrecordfromtheDNSand(ii)certicatesviaSTARTTLSisnotsufcienttoproperlyoperateDANE.
TheCertificateAssociationDataoftheTLSArecordsmustbecorrectandconsistentwiththecerticatepresentedbytheemailserver.
DNSSECvalidation:Weexaminethecorrectnessandfresh-nessoftheRRSIGsrecordsofTLSArecords.
Tothisend,weuseUnbound[76]tofetchallthenecessaryDNSrecords(e.
g.
,DNSKEYsandDSrecordsandtheircorrespondingRRSIGs),andverifytheTLSArecordsbasedonthetimeofthescan.
ThereasonsfortheDNSSECvalidationfail-urescanbeexpiredRRSIGs,RRSIGsinconsistentwiththeirDNSKEYs,malformedRRSIGs,etc.
Certicatevalidation:WealsoexamineiftheTLSArecordsareconsistentwiththepresentedcerticates.
Tothisend,webuildavalidationprogramusingtheOpenSSLlibrarytoverifygivencerticatesbasedontheCertificateUsageintheTLSArecords.
6Thereasonforcerticatevalidationfailurescanbe6WealsousedtheattimeoptiontohaveOpenSSLvalidatethecerti-catesasofthetimeofthescan.
62029thUSENIXSecuritySymposiumUSENIXAssociationmismatchedCertificateUsage,Selector,MatchingType,orCertificateAssociationData.
Figure7showsthedistributionofthevalidationfailurerea-sonsduringourmeasurementperiod.
Wemakethefollowingobservations:First,wendthatmostoftheTLSArecordsconguretheirDNSSECproperlyiftheydonotmissanyrelatedDNSSECrecords;theaveragefailurerateisonly0.
47%.
Comparedwiththerecentstudy[23]reportinga0.
5%failurerateofRRSIGsofsigneddomains,thisresultindicatesthatTLSArecordsaremanagedsimilarlywell.
Focusingonthevalidationfailurereason,wendthatexpiredRRSIGsaretheprimaryreason(70%ofthefailures)andtheother30%areduetonon-existentDNSKEYs.
Second,wendthatonaverage14.
17%ofthecer-ticatescannotbevalidatedduetoamismatchwiththeircor-respondingTLSArecords;2.
7%oftheseerrorsarecausedbyawrongSelectororCertificateUsage.
Inotherwords,wecanmakethemvalidsimplybychangingtheoptionnum-beroftheSelectororCertificateUsage.
Theothers(97.
3%)areduetoCertificateAssociationDatathatdoesnotmatchwithanycerticateinthechainpresentedbytheTLSserver.
Onepossibleexplanationisthattheadmin-istratorsforgottoupdateeitherTLSArecordsorcerticateswhenchangingtheirpublickeys,whichweconsiderinmoredetailinsubsection5.
5.
5.
4ImpactofTLSAValidationFailureAsexplainedinsection4,apopularemailserver(MXrecord)canbeusedbymanydomains,meaningthatthevalidationfailureofasingleTLSArecordcanaffectmanydomainsthatrelyonitsMXrecord.
WenowcombineourDailyandHourlydatasetstoanalyzehowmanydomainshaveTLSArecordswithmissingorincorrectDANEcomponents,allowingustoestimatetheimpactofTLSArecordvalidity.
Figure8showsthepercentageofdomainsthathaveTLSArecordsthatcannotbevalidatedbysendingemailclients,classiedbytheirTLDs.
Asthegureshows,theimpactvariesacrossTLDs;forex-ample,only0.
006%of.
sedomainscannotbevalidatedduetomissingorinvalidDNSSECorSTARTTLScongurations,while.
orgdomainsshowamuchhighererrorrateof1.
65%,whichis275timeshigher.
Interestingly,weobserveonly30150.
sedomainswithincorrectormissingTLSArecords.
Webelievethissuccessindeploymentisrelatedtothe.
seregistry'sconsistenteffortstodeployTLSArecordsandDNSSECbyofferingnancialincentivestoregistrars[23,51]thatdeploythesetechnologiescorrectly7.
Surprisingly,foralmost8,200.
nldomains,theTLSArecordswereinvalidfor7hoursonOctober19,2019.
ThiswasmainlyduetofourTLSArecordssharingthesame7Similarly,the.
nlregistrymanagesaprogramcalledRegistrarScore-card,whichoffersnancialincentivestoregistrarswhoenableandmanageInternetsecurityprotocolssuchasDKIMandDNSSEC[67,78].
Figure8:ThepercentageofdomainswithmisconguredTLSArecordsisshown.
second-leveldomain,mailplatform.
eu8.
Frommanualin-spection,wendthattheirDNSSECsignatureswerenotvalidduetonoDNSKEYsmatchingtheDSrecordintheparentzone.
WesuspectthattheymadeamistakeduringtheupdateoftheirDSrecordsandDNSKEYs.
5.
5TLSAManagementTheprevioussectionsfocusonthenecessaryandcorrectcomponentstoprovidevalidcerticates,whichareconsistentwiththeTLSArecords.
Inthissubsection,wefocusonhowTLSArecordsandthecorrespondingpublickeysaremanaged;morespecically,weinvestigateiftheTLSArecordsareusedasintendedandhowoftenpublicandprivatekeypairsarechanged.
UnsuitableUsagesTheprimarypurposeofDANEistoletdomainownersusecustomcerticatesfortheirTLSconnec-tionsbyusingTLSArecordswiththeDANE-EEorDANE-TAusagewithoutrelyingonthirdpartyCAs.
IfthedomainownerhasacerticateissuedbyaCA,butservesaTLSArecordwiththeDANE-EEorDANE-TAusage,theydonotbenetfullyfromthesecuritymeasuresthatDANEprovides(instead,theyshouldusethePKIX-EEorPKIX-TACertificateUsage).
Moreover,thevalidityperiodsofsuchcerticatesareusuallydeterminedbyCAs,whichareusuallyshort.
9Thus,domainownersincuradditionalcomplexityastheyneedtoupdatetheirTLSArecordswheneverthecerticatesarere-issued.
Therefore,adomainnameownershouldavoidsettingtheirTLSArecordswiththeDANE-EEorDANE-TAusagewhentheyserveacerticateissuedbyaCA.
WerstexaminehowtheCertificateUsageeldissetinTLSArecordsbycalculatingthedistributionoftheCertificateUsagesoftheTLSArecordsfromourlatestsnapshot.
Unsurprisingly,weobservethatthevastmajorityofTLSArecords(94.
29%)useDANE-EEorDANE-TA.
WethencongureOpenSSL[61]totrustthesetofrootCAcerti-8_25.
_tcp.
antispam.
mailplatform.
eu,_25.
_tcp.
antispam-alt.
mailplatform.
eu,_25.
_tcp.
mx-alt.
mailplatform.
eu,and_25.
_tcp.
mx.
mailplatform.
eu9ThelifetimeofthecerticatesissuedbyLetsEncryptis3months[52].
USENIXAssociation29thUSENIXSecuritySymposium621catesintheUbuntu18.
04LTSrootstore[24];thevalidationwouldfailifthecerticatesfortheTLSArecordsarecustomcerticates.
Surprisingly,wendthatonaverage90.
58%and90.
37%ofTLSArecordswithDANE-EEandDANE-TAarestillvalid,whichmeansthatthecerticatesarevalidintermsofPKIX,notcustomcerticates.
Consequently,theserecordscouldhaveusedPKIX-EEorPKIX-TACertificateUsages,thushavingtheadditionalbenetofcerticateval-idationthroughtwoindependentmechanisms(DANEandPKIX).
Webelieveoperatorsdothisbecausetheyarewor-riedthatsendingSMTPserverswouldrejecttheircustomcerticates.
However,aswewillseeinthenextsection,allofthepopularemailserviceproviders(i.
e.
,sendingSMTPservers)thatwetestdonotvalidatethecerticatesofthereceivingSMTPserverswhentheycannotndanyavailableTLSArecords.
KeyRolloverJustlikeotherPKIs,DANEalsoprovidesamethodforaTLSservertochangeitspublicandprivatekeypairs.
Thisprocessiscalledkeyrollover,andthebestcurrentpracticeforexecutingsucharolloverisspeciedinanRFC[28].
However,unlikeotherPKIs,DANErequiresmorecare-fulconsiderationwhenperformingkeyrolloversbecauseofoldDNSrecordscachedonresolvers.
RecallthatallDNSresponses(includingTLSArecords)eachcontainaTTLeldindicatinghowlongagivenrecordmaybecached.
Thus,ifanSMTPserversimplyswitchestoanewcerticateandpub-lishesitscorrespondingTLSArecordimmediately,thecachedoldTLSArecordscanresultinamismatchtothenewcer-ticate,causingavalidationfailureinsomeSMTPclients.
Thus,beforerollingovertoanewcerticate,theadministra-torneedstopublishanewTLSArecordinadvance(atleasttwoTTLsoftheoldTLSArecords),whilekeepingtheoldonetolettheDNSresolversofSMTPclientsfetchthenewandoldTLSArecordstogether.
WeexaminehowfrequentlySMTPserversrolltheirkeys,andwhentheydo,iftheydothiscorrectly.
WeonlyconsiderchangeswheretheactualpublickeyinthecerticateandTLSArecordchanges.
Thisisrelevantbecause,asdiscussedearlier,TLSArecordshaveaMatchingTypeoptionthatspecieshowcerticatesandTLSArecordsshouldbematched.
IftheMatchingTypeindicatesthatmatchesshouldbeperformedbasedonthepublickeyonly,thecerticatecanberenewedwhileretainingthesamekey(whichextendsthevalidityofthecerticatewithoutanactualkeyrollover).
WerstltercerticatesandTLSArecordsthatwecanmonitorfortheentiremeasurementperiod,whichleavesus10,382certicates(andtheircorrespondingTLSArecords).
Amongthecerticates,wendthat7,334(70.
6%)certicateshaveneverchangedtheirpublickeys.
Wethenseewhethertheother3,048certicateshavechangedtheirkeyscorrectly.
Toanalyzetherolloverbehav-iorsmoreaccurately,weremovetheTLSArecordsfromourconsiderationswhen(1)theirTTLsareshorterthanourscanresolution(i.
e.
,1hour),(2)theircorrespondingcerticateshaveneverbeenvalid10,and(3)wecouldnotcapturetheircorrespondingcerticateswhentherolloverhappenedduetoserverormeasurementerrors.
Afterltering,thisleaves1,460(47.
9%)TLSArecordsandtheircerticates.
Wemakethefollowingobservationsfromouranalysisforthisdataset:First,weobservethatonly124domains(8.
5%)domainshavemaintainedtwoormoretypesofTLSArecordswithmixedusagessuchasmaintainingDANE-EEandDANE-TAtogether;thisallowsadministratorstochangetheleafcerti-cateanditsTLSArecordswithDANE-EEusageimmediatelyaslongasitissignedbythecerticatethattheTLSArecordswithDANE-TAusagespecify.
Duetothisadvantage,wendthat109(87.
9%)ofthemsuccessfullyrolltheirkeyswithoutanyvalidationfailures.
Second,wendthat1,335domains(91.
4%)haveasingleTLSArecordusage;inthiscase,theadministratorsneedtomakesurethattheypre-publishthenewTLSArecordswellinadvanceofakeyrollover.
How-ever,weobservethatthevastmajorityofthem(1,257or94.
2%)experienceatleastonevalidationfailureduringtheirrollovers.
Fromfurtherinvestigation,weobservethat939ofthem(74.
7%)introducednewcerticatesandthecorre-spondingTLSArecordsatthesametimewithoutconsideringtheTTLoftheTLSArecordsoronlyintroducednewTLSArecordsafterchangingcerticates.
Theseresultshighlightthechallengesforcorrectlyupdat-ingthekeysintwodifferentplacesinDANE.
ConsideringthatauthoritativeDNSserversandSMTPserversprovidetwodisjointfunctions,administratorsneedtoaddanewTLSArecordontheDNSserverinadvance,andneedtoinstallthenewcerticateintheirSMTPservermanuallyafterwaitingatleasttwoTTLs.
6Client-sideDANESupportEvenifdomainsproperlymanagetheirTLSArecordswithDNSSECandprovidevalidcerticatesthatcomplywiththecerticate-relateddatainTLSArecords,anSMTPclientcan-notbeprotectedunlessitlooksupandveriesTLSArecordscorrectly.
WenowexaminehowDANEissupportedintherealworldbyexamining(1)popularemailserviceprovidersand(2)popularMailTransferAgent(MTA)andDNSsoft-ware.
6.
1PopularEmailServiceProvidersWerstexaminehowpopularemailserviceprovidershavedeployedDANEtoauthenticatedestinationmailserversandencryptemailtransport.
Inordertoobtainalistofpopu-laremailproviders,weusetheapproachfromapreviousstudy[36];werefertoAdobe'sleakeduseremaildatabase10Inthiscase,wecannotdeterminewhethertheyconductcorrectrollovers.
62229thUSENIXSecuritySymposiumUSENIXAssociationFigure9:Timelineformeasurementofanemailprovider'sDANEsupport:wesignupforanaccountandsendanemailtoourtestbedserverxy;theemailproviderlooksupourdomain'sMXrecordandTLSArecord(ifitsupportsDANE)viaitsDNSresolverorbyitselfz;ourauthoritativeDNSserverchecksif(a)theemailproviderhastriedtolookuptheTLSArecordand(b)settheDObitintheheader{|;theemailproviderinitiatesanSMTPconnectionandsendstheSTARTTLScommand(ifitsupportsSTARTTLS).
Oncetheconnectionismade,theemailistransferred};ourtestbedSMTPserverchecksiftheemailhasbeensuccessfullydelivered~.
from2013[43]toranktheemaildomainsbasedonpopularityandchoosethetop25providers.
Wealsoaddrecentpopularemailserviceproviders:protonmail.
com,tutanota.
com,zoho.
in,fastmail.
com,andrunbox.
com.
Intotal,wehave29popularemailserviceprovidersthatcover83millionemailaddresses(54%)intheAdobedatabase.
ThelistoftheemailserviceprovidersisshowninTable3.
Inthefollowing,wedescribethedetailsofourmeasurementmethodology.
ExperimentSetupThegoaloftheexperimentsistoinves-tigatehowpopularemailserviceproviders,asSMTPclients,properlysupportDANE.
Todoso,werstpurchaseasecond-leveldomainname(e.
g.
,foo.
com)asanSMTPserverinourtestbed,whichisconguredtofullysupportDNSSECbyup-loadingDSrecordstoitstop-leveldomain,the.
comzone.
WeuseBIND[2]torunourauthoritativeDNSserver,whichhasDNS/DNSSECrecordsfor15differentsubdomains.
Also,weusePostx[65]asourSMTPserver.
WeconguretheSMTPservertosupportSTARTTLSandenabletheServerNameIn-dication(SNI)[14]extensiontoservedifferentcerticatesforindividualsubdomainnames.
NotethattheSMTPclients(i.
e.
,29emailserviceproviders)alreadysupportthesefunctions.
Wetest15subdomainsmappedtodifferentMXrecords;14subdomainsareconguredtotestadifferentcombinationofDNSSEC,STARTTLS,andDANEmiscongurations,whileonesubdomainiscorrectlycongured.
1111Toavoidanypotentialcachingissuesatintermediateresolvers,wesettheTTLvaluesofMXandTLSArecordstoonesecond;however,ifsomeemailserviceproviderswouldhappentosendDNSqueriestotheexactsameresolver(e.
g.
,oneofthemultipleupstreamresolversbehindGoogleDNS),itcouldignoreourTTLvalue,whichwouldinterferewithourexperimentresults.
Tominimizethispotentialissue,wetestedallemailserviceprovidersWethenproceedasfollowsasillustratedinFigure9.
1.
Foreachemailserviceprovider(e.
g.
,gmail.
com),werstsetupanaccountasanemailsender(e.
g.
,sender@gmail.
com).
2.
Foreachtransmissionofanemail,wepickoneofthe15testbedsubdomains(e.
g.
,dnssec-invalid-rrsig.
foo.
com)towhichanemailissentbyanemailserviceprovider(sender@gmail.
com).
3.
TheemailserviceproviderrstlooksupanMXrecordofthetestbedsubdomainbysendingaDNSrequesttoitsDNSresolver,whichultimatelyforwardstoourauthorita-tiveDNSserver.
Thus,wecanlearntheIPaddressoftheresolveronwhichtheemailserviceproviderrelies.
4.
IftheincomingDNSrequestfromtheresolverdoesnotsettheDObit,itindicatesthattheresolverdoesnotsupportDNSSEC.
5.
AswewishtoseewhetherDANEisenabledintheemailserviceprovider(anditsDNSresolver),wecheckiftheDNSresolveralsomakesaDNSrequestforTLSArecords.
6.
Wethencheckiftheemailserviceprovider(asanSMTPclient)successfully(1)initiatesanSMTPconnectiontoourdestinationemailserver,and(2)sendstheSTARTTLScommand.
Ifso,ourDNSserverprovidesavalidorin-validcerticate(dependingontherequestedsubdomainname).
Incaseofaninvalidcerticate,weobserveiftheemailserviceproviderstillcontinuestoestablishtheTLSconnection.
7.
Finally,wecheckiftheemailhasbeensuccessfullydeliv-eredtoouremailserver.
Ifouremailserverfailstoreceivetheemailsenttoamisconguredtestsubdomain,itmeansthattheemailserviceprovider(anditsDNSresolver)hascorrectlyvalidatedthemisconguredsubdomain,andde-cidednottosendtheemail.
ExperimentCongurationsAtrstglance,measuringwhetheranemailserviceprovider(i.
e.
,SMTPclient)cor-rectlysupportsDANEseemstrivial.
WecancongureourDNSservertosupportDNSSECandtoserveTLSArecords.
Also,thedestinationemailserver(i.
e.
,SMTPserver)iscon-guredtosupportSTARTTLSwithacerticateforeachsub-domainname;notethatsomecerticatesareinconsistentwiththeCertificateAssociationDatavaluesintheircorrespondingTLSArecordsdependingonthemiscongura-tionsettings.
Then,theSMTPclientwillsendanemailtotheSMTPserver;wewillcheckwhethertheemailissuccessfullyreceived.
Thismaybesufcientforstudyingemailserviceprovidersatacoarsegranularity.
Howeverwestillwouldnotunderstandwhichprotocolsare(not)supported,orwhichmechanismsare(in)correctlyimplemented.
Tounderstandthene-grainedbehaviorofeveryemailserviceprovider,weatleast5timesoveramonthtomakesuretheyperformconsistently.
USENIXAssociation29thUSENIXSecuritySymposium623havetotesteachprotocolseparatelybyincorrectlycongur-ingonlyoneoftheDANE-relatedprotocolswhilekeepingtheotherscorrectlycongured.
Tothisend,wecongureourtestsubdomainsandtheiremailserversasfollows:DNSSEC:TheDNSresolverofanemailserviceprovidermustsupportDNSSECtochecktheintegrityandauthen-ticityofTLSArecords.
InordertoexaminewhethertheDNSresolvervalidatesDNSresponsescorrectlyusingDNSSEC,werstintroducefourdifferentmisconguredsubdomainswhoseMXrecordshavemissing,incorrect,orexpiredRRSIGs,ormissingDNSKEYs.
Thentheemailser-viceprovidersendsanemailtoeachofthefoursubdomains.
Wenallycheckwhethertheemailhasbeensuccessfullyreceived.
Typically,SMTPclients(i.
e.
,emailserviceproviders)thatrequireDNSlookupsoutsourceDNSSECvalidationtotheirDNSresolvers;DNSSEC-supportingresolversfetchandvalidateDNSresponsesonbehalfoftheirclients.
IfaDNSresponseisinvalid,theDNSresolverreturnsaSERVFAILresponsetotheSMTPclient.
Otherwise,itfor-wardstheDNSresponsetotheSMTPclientandsetstheAuthenticatedData(AD)bitintheresponse.
Insomecases,theDNSresolverthatanSMTPclientusesresidesoutsideitsownadministrativedomain(e.
g.
,itusesapublicDNSresolverlikeGooglePublicDNS[31]).
WeexaminewhethertheDNSresolverismanagedbyathirdpartysuchasapublicDNSresolverusingaWHOISlookup(e.
g.
,itsASnumber).
Thereasonwedothisisthataman-in-the-middleattackermayinterfereintheDNSlookupprocesstowardsaresolveroutsideoftheSMTPclient'sadministrativedomain.
Forthisreason,theDANEstan-dardstronglyrecommendsagainsttheuseofexternalDNSresolvers([38],section8.
3).
STARTTLS:TheSMTPclientmustsendtheSTARTTLScommandtothedestinationemailserver(i.
e.
,SMTPserver)tofetchandvalidatetheSMTPserver'scerticate.
Thus,wemaketheSMTPclientauthenticatetheSMTPserver(beforesendinganemail)andcheckifitsendstheSTARTTLScommandafternegotiatinganSMTPconnec-tionwiththeSMTPserver.
OurSMTPserverpresentsaninvalidcerticate,andwewillcheckwhethertheSMTPclientvalidatesit.
Tothisend,theDNSserverdoesnotprovidethecorrespondingTLSArecords.
TheSMTPserverintentionallyservesaPKIX-invalidcerticatesuchasanexpiredorself-signedone,oracerticatewhoseCommonNameisnotconsistentwiththeoneintheMXrecord.
Uponreceiptofthecerticate,theSMTPclienteither(i)detectstheinvalidcerticate(andtheSMTPconnectionistermi-nated),or(ii)acceptstheinvalidcerticatewithoutanyauthentication(thustheSMTPconnectionisestablished).
SincetheSTARTTLSRFC[37]doesnotspecifywhataclientshoulddoforaninvalidcerticate,itistotallyuptotheimplementationoftheSMTPclient.
Wethencheckwhethertheemailhasbeensuccessfullyreceived,whichmeanstheSMTPclientfailstovalidatecerticates.
DANE:Finally,weinvestigatewhetheremailserviceprovidershavedeployedDANEvalidationandwhethertheydosocorrectly.
Tothisend,weintroducefourincor-rectlyconguredsubdomains;theTLSArecordsofthefoursubdomainseachhaveawrong(1)CertificateUsage,(2)Selector,(3)MatchingType,or(4)CertificateAssociationDatathatdoesnotmatchthepresentedcer-ticate.
12BeforetheSMTPclientsendstheemail,wealsocheck(1)ifitsDNSresolveralsohasresolvedaTLSArecordfromourauthoritativeDNSserver,(2)ifitinitiatesanSMTPconnectionwiththeSTARTTLScommand,(3)ifitterminatesconnectionaftertheSMTPserverpresentsamisconguredcerticate,and(4)ifitperformsthevalida-tionofTLSArecords,and(5)ifitdetectstheCertificateAssociationDataintheTLSArecord(s)isinconsistentwiththeSMTPserver'scerticate.
ExperimentresultsFromtheexperiments,weobserve(1)howtheemailserviceprovidersdeployDNSSEC,START-TLS,andDANE,and(2)ifthecorrespondingprotocolsarecorrectlyimplemented.
First,weobservethat4outof29emailproviders(excite.
com,gmail.
com,andgmailinbox,andoutlook.
com)useDNSresolversthatdonotsupportDNSSECexplicitlybysendingDNSrequestswithoutsettingtheDObit.
Interestingly,wefoundthatgoogle.
comandgmailinboxhavetriedtofetchMTA-STSrecords[53];notethatMTA-STSisanalternativetoDANEtoauthenticatedestinationemailservers.
AstheycannotchecktheintegrityandauthenticityoftheMTA-STSrecords,however,theyarevulnerabletoman-in-the-middleattacks[53],whichcanmanipulateordropMTA-STSlookupsorredirectthemtoawrongdestinationmailserver.
Amongthe26emailserviceproviderswhoseDNSresolversenabletheDObit,onlysevenemailserviceprovidersfetchDNSKEYsandDSrecords.
Itisaseriousissuethatthe19emailserviceprovidersdonotfetchDNSKEYsandDSrecordseveniftheDObitisset.
Thus,23(i.
e.
,4+19)emailserviceprovidersarestillsusceptibletoDNSpoisoningattacks.
Thisresultisinlinewiththerecentstudy[22],whichshowedthat82%oftheDNSresolversmanagedbylocalISPsactuallydonotperformDNSSECvalidation.
Evenmorealarmingly,ofthesevenemailserviceprovidersthatdofetchDNSKEYsandDSrecords,wendthatthreeemailproviders(mynet.
com,sapo.
pt,andsina.
com)explicitlydisableDNSSECvalidationbysettingtheCDbit.
Thus,theirresolversincurthecommunicationsoverheadforDNSSECresponsesincludingDNSKEYsandDSrecords,whosesizesaremuchlarger(byafactorof6*12*)thanthoseofDNS(i.
e.
,non-DNSSEC)responses[81],butdonotbothertovalidatetheresults.
Finally,weobserve12AllothersettingssuchasDNSSECandSTARTTLSarecorrect.
62429thUSENIXSecuritySymposiumUSENIXAssociationMailProviderDNSSECSTARTTLSDANEDObitRequestedValid-ationSameOp.
Cmd.
SentCorrectlyRejectedTLSACorrectlyRejectedExpiredSelfCNNoWrongDNSKEYDSCertSignedUnmatchPub.
Req.
CertUsageSelectorMatchCertmail.
comcomcast.
netgmx.
comtutanota.
commynet.
comsapo.
ptsina.
comprotonmail.
comaol.
comfastmail.
comfreemail.
humail.
runaver.
comrediffmail.
comyahoo.
comzoho.
indaum.
netinteria.
plinbox.
lvicloud.
comrunbox.
comseznam.
czo2.
plwp.
plsohu.
comt-online.
deexcite.
comgmail.
comoutlook.
comTable3:Tableshowingthetop29popularemailproviders'supportforDNSSEC,STARTTLS,andDANE;ifemailprovidersdonotsupportSTARTTLS,wedonottestiftheyacceptanexpired,self-signed,CommonNamemismatchedcerticate(hencethe–).
Similarly,iftheydonotfetchTLSArecordswealsodonottestiftheyacceptthewrongTLSArecords(hencethe–).
that9outof29mailserviceprovidersuseDNSresolversoutsidetheirownnetwork,whichmakesthemvulnerabletoman-in-the-middleattacks(SameOp.
columninTable3).
Second,wealsoobservethat24outofthe29mailserviceproviderssupportSTARTTLS;thisisinlinewithapriorstudy[30],whichshowedthat81.
8%ofAlexa1MdomainssupportSTARTTLS.
However,wendthatnoneofthe24emailserviceproviderscorrectlyverifypresentedcerticates;theysuccessfullycompletetheTLShandshakeeventhoughdestinationemailserverspresentexpiredorself-signedcer-ticates,orevencerticateswhoseCommonNameeldsareinconsistentwiththeircorrespondingMXrecords.
WebelievethisisduetothelackofspecifyingwhattodoincaseofinvalidcerticatesinSTARTTLS[37].
Thisresultisalsoinlinewithpriorwork[30]thatstudiedtheSTARTTLSsupportofpopularemailserviceproviders;only52%ofpopularemailserverspresentvalidcerticates.
However,ourresultssuggestthatpopularemailserviceprovidersneverauthenticatethecerticatesofthecounterparts,whichstronglymotivatestheneedtodeployDANEforsecuringincomingandoutgoingemails.
Third,wendthatonlyfouremailserviceproviders(mail.
com,comcast.
net,gmx.
com,tutanota.
com)ac-tuallyfetchTLSArecords.
Fortunately,wendthatthesefouremailserviceproviderscorrectlyrejectTLSArecordsiftheirSelector,MatchingType,orCertificateAssociationDataeldisnotvalid.
Equally,theyalsorefusetoconnectifourtestserverrefusestoinitiateaTLSconnection(NoCertcolumn).
However,weobservethatmail.
com,tutanota.
comdonotcheckwhethertheCertificateUsagevalueoftheTLSArecordisconsis-tentwiththecerticate.
Thatis,wepresentaself-signedcerticatethroughSTARTTLS,buttheTLSArecordsetsitsCertificateUsagetoPKIX-EE.
Giventhatself-signedcer-ticatescanneverbePKIXvalid,theyshouldhaverejectedtheinvalidcerticatesduringtheTLShandshake.
Therearetwopossiblehypothesesforthis;theymight(1)ignoreaTLSArecordwhoseCertificateUsageiseitherPKIX-TAorPKIX-EE(astheseusagesarenotrecommended[28]),or(2)skipthePKIXcerticatevalidationexceptforcheckingtheCertificateAssociationData.
Totestourhypothe-sis,weintroduceanothersubdomainthatservesaTLSArecordwiththePKIX-EEusageandwithawrongCertificateAssociationData.
Thus,iftheyignoretheentireTLSArecord,thenourcerticatewouldbeacceptedandtheemailwouldbedeliveredsuccessfully;iftheyskipthePKIXvalida-tion,theinvalidcerticatewouldberejected,thustheemailwouldnotbetransmitted.
Fromtheadditionalexperiment,wendthattheemailisnottransmittedtothissubdomain,imply-ingthattwomailserverscurrentlyskipthePKIXvalidationexceptforcheckingtheCertificateAssociationData.
USENIXAssociation29thUSENIXSecuritySymposium6256.
2PopularMTAsandDNSsoftwareTodeployDANEintheSMTPprotocolatalargerscale,thesoftwareofMailTransferAgents(MTAs)andDNSre-solvers/serversmustbecorrectlyimplemented.
Ifemailser-viceproviderswishtosupportDANE,(1)thesoftwareoftheirDNSserversandDNSresolversmustbeabletounder-standTLSArecordsandtosupportDNSSECtovalidateDNSresponses,and(2)theirSMTPsoftwaremustlookupandvalidateTLSArecordsalongwiththecorrespondingcerti-cates.
Morespecically,sendingMTAs(i.
e.
,SMTPclients)mustbeableto(1)lookupTLSArecordsbythemselves,orusetheirDNSresolverstolookupandvalidateTLSArecords,(2)sendtheSTARTTLScommandtoreceivingMTAs(i.
e.
,SMTPservers),and(3)validatethecerticatesofthereceiv-ingMTAswiththecorrespondingTLSArecords.
Thereceiv-ingMTAsmust(1)deployDNSserversthatcanserveTLSArecordsandsupportDNSSECtosigntheirDNSrecords,and(2)supportSTARTTLStopresenttheircerticatesconsistentwiththeTLSArecords.
However,itremainsunclearwhethertheMTAandDNSsoftwareachievestheaboveobjectives[39].
Inthissection,weexaminewhetherthepopularMTAandDNSsoftwarecorrectlysupportsDANEfromtwoperspectives:DANEforoutgoingemails:UnlikeotherSMTPexten-sionsthatimposeresponsibilitiesonreceivingMTAstoau-thenticatesendingMTAs(e.
g.
,SPF,DKIM,andDMARC),DANErequiresthesendingMTAsandtheirDNSresolverstoexecutethefollowingtasks:(1)fetchthereceivingMTA'scerticatethroughSTARTTLS,and(2)verifythecerticateswiththeirTLSArecords.
Thus,werstexaminewhetherpopularSMTPsoftwaresupportsSTARTTLSfortheiroutgoingemails,sendsTLSArequests,andveriesthefetchedcerticates.
Additionally,wealsocheckwhethertheSMTPsoftwareresolvesDNSrecordsbyitself(thusanSMTPclientbecomesarecursiveresolver),orreliesonDNSresolverstolookupDNSrecordsonitsbehalf(thusanSMTPclientbecomesastubresolver).
Asdiscussedinsubsection6.
1,iftheSMTPclientsoftwarelooksupTLSArecords,itisrecommendedtoresolvetheDNSrecordsbyitselftoblockman-in-the-middleattacks.
FortheMTAsoftwareleveragingexternalrecursiveresolvers,wealsocheckwhetherthepopularDNSsoftwareunderstandsTLSArecordsandsupportsDNSSECasarecursiveresolver.
DANEforincomingemails:ItisrelativelyeasytoenableDANEforincomingemails.
TheMTAsoftwareneedstoenableSTARTTLSanditsDNSserverneedstoserveTLSArecordsthataresignedcorrectlyandconsistentwiththecerticate.
SelectingpopularMTAandDNSsoftwareToobtainalistofpopularopensourceMTAprograms,werefertoapriorstudythatshowedfourpopularMTAs(Exim,Postx,MTASoftwareSMTPasaClientServerDNSSTART-TLSArecordsSTART-ResolverTLSReq.
Valid.
TLSPostx3.
4.
7[65]StubExim4.
92.
3[4]Stubsendmail8.
15.
2[71]Stub-ExchangeServer2019[3]Stub-Table4:ExperimentresultsonfourpopularSMTPsoftwareimple-mentationsoftheirsupportforSTARTTLSandDANE.
DNSDNSSupportSoftwareAuth.
RecursiveDNSSECTLSABIND99.
14.
7[2]PowerDNS4.
2.
0[9]MicrosoftDNS[7]SimpleDNSPlus8.
0.
110[10]NSD4.
2.
2[8]KnotDNS2.
9.
0[5]YADIFA2.
3.
9[11]djbdns1.
05[84]MaraDNS3.
4.
01[6]posadis0.
60.
6[63]Table5:ExperimentresultsontenpopularDNSsoftwareimple-mentationsofDNSSECandDANE(TLSArecords).
Amongthem,sevenimplementationssupportbothprotocolscorrectly.
Sendmail,Exchange13),togetherhada61%marketsharein2015[30].
ToobtainalistofpopularopensourceDNSprograms,werefertopriorwork[54]thatidentiedDNSsoftwareprogramsrunningonsecond-leveldomainsforthe.
com,.
net,.
orgTLDs.
Intotal,weinvestigatedtenDNSsoftwareprograms.
ResultsOurresultsaresummarizedinTable4andTable5;wemakethefollowingobservations.
First,wenotethatalloftheSMTPprogramsrelyonexternalrecursiveresolverstoresolveTLSArecords14.
ConsideringthatastubresolvercanchecktheauthenticityofTLSArecordsonlybytheADbitsetbyitsrecursiveresolver,asendingMTAmaywishtoinstallitsownrecursiveresolversupportingDNSSECandDANE(Table5)toverifytheDNSrecordsbyitself,therebyreducingtheattackvectors.
Second,wenoticethatalloftheMTAprogramssupportSTARTTLSforbothincomingandoutgoingemails.
However,wendthatonlyEximandPostxsupportDANE.
Third,focusingontheDNSsoftware,wendthatsevenofthetestedDNSprogramssupportDNSSEC.
Thus,receivingMTAs(i.
e.
,SMTPservers)thatwishtoassuretheauthenticityoftheiridentitiesandguaranteethecondentialityofemailtransport,caneasilydeployDANEbyservingsignedTLSArecords.
However,wendthreeDNSprogramscannotfetchTLSArecordsyet.
ThusthereceivingMTAsoutsourcingtheirDNSlookupstothoseresolverscannotauthenticatesendingMTAseveniftheyusetheDANE-supportingMTAsoftware.
13Thisisnotopensource,butcommercialsoftwarerunningonMicrosoftWindowsServer.
14However,welearnedthatsomecommercialSMTPprogramslookupDNSrecordsbythemselvessuchasCisco'sAsyncOSEmailSecurityAppliance[1]62629thUSENIXSecuritySymposiumUSENIXAssociation6.
3SummaryInsummary,DANEsupportinpracticeispooramong29popularemailserviceproviders:onlyveofthemsupportDANEforincomingemailsandfourofthemsupportDANEforoutgoingemails.
AmongthefouremailserviceproviderssupportingDANEforbothincomingandoutgoingemails,onereliesonexternalDNSSEC-awareresolvers,whichmightbevulnerabletoMITMattacks.
Onthebrightside,DANEsupportinthepopularMTAandDNSprogramsispervasive;allMTAssupportSTARTTLSforincomingemails,andtwoofthemvalidatethepresentedcerticateswiththeirTLSArecordsforoutgoingemails.
Also,sevenDNSprogramssup-portbothDNSSECandTLSArecords;astotheothersnotsup-portingDNSSECandDANE,thelatestversionsofdjbdnsandposadiswerereleasedmorethan15yearsago[12,64],andMaraDNSdoesnotsupportDANEyetdespitebeingup-datedrecently.
Thus,webelievethattheadministratorsofthoseemailserviceprovidersthatdonotsupportDANEyetcaneasilysupportDANEbyupdatingandconguringMTAandDNSsoftware.
7ConclusionThispaperpresentsalongitudinalandcomprehensivestudyoftheDANEecosysteminSMTP—encompassing178Msecond-leveldomainsand29popularemailserviceproviderstounderstandthesecurityimplicationsofhowDANEis(mis)managed.
Wefoundthat(1)DANEdeploymentisscarcebutincreasing,(2)morethanonethirdofalltheTLSArecordscannotbevalidatedduetomissingorincorrectDNSSECrecords,and(3)14%ofthecerticatesareinconsistentwiththeirTLSArecords.
OntheSMTPclientside,wemeasured29popularemailserviceproviderstounderstandhowtheysupportDANE;wefoundonlyfourofthemsupportDANEforbothoutgoingandincomingemails,andoneemailserviceproviderdoessoonlyforincomingemails.
WealsotestedfourMTAandtenDNSsoftwareprograms,andfoundthattwooftheMTAandsevenoftheDNSprogramssupportDANEcor-rectly,whichimpliesthattheadministratorswillingtodeployDANEwouldnotndanyoperationalchallenges.
AcknowledgmentsWethanktheanonymousreviewersandourshepherd,PaulPearce,fortheirhelpfulcomments.
Thisresearchwassup-portedinpartbyNSFgrantsCNS-1850465andCNS-1901090,anInstituteofInformation&communicationsTech-nologyPlanning&Evaluation(IITP)grantfundedbytheKoreagovernment(MSIT)(No.
2016-0-00160,VersatileNet-workSystemArchitectureforMulti-dimensionalDiversity),SURFnetResearchonNetworksandEUH2020CONCOR-DIA(#830927).
References[1]AsyncOSEmailSecurityAppliance.
https://www.
cisco.
com/c/ko_kr/products/security/email-security-appliance/index.
html.
[2]BIND9.
https://www.
isc.
org/bind/.
[3]ExchangeServer.
https://docs.
microsoft.
com/ko-kr/Exchange/exchange-serverview=exchserver-2019.
[4]Exim.
https://www.
exim.
org/.
[5]KnotDNS.
https://www.
knot-dns.
cz/.
[6]MaraDNS.
https://maradns.
samiam.
org/.
[7]MicrosoftDNS.
https://docs.
microsoft.
com/ko-kr/windows-server/networking/dns/dns-top.
[8]NSD.
https://www.
nlnetlabs.
nl/projects/nsd/about/.
[9]PowerDNS.
https://www.
powerdns.
com/downloads.
html.
[10]SimpleDNSPlus.
https://simpledns.
com/.
[11]YADIFA.
https://www.
yadifa.
eu/.
[12]djbdns1.
05Release.
https://github.
com/abh/djbdns/blob/master/CHANGES.
[13]STARTTLSenDANE.
2016.
https://www.
forumstandaardisatie.
nl/standaard/starttls-en-dane.
[14]D.
E.
3rd.
TransportLayerSecurity(TLS)Extensions:ExtensionDenitions.
RFC6066,IETF,2011.
[15]C.
Arthur.
DigiNotarSSLcerticatehackamountstocyberwar,saysexpert.
TheGuardian.
http://www.
theguardian.
com/technology/2011/sep/05/diginotar-certificate-hack-cyberwar.
[16]R.
Arends,R.
Austein,M.
Larson,D.
Massey,andS.
Rose.
DNSSecurityIntroductionandRequirements.
RFC4033,IETF,2005.
http://www.
ietf.
org/rfc/rfc4033.
txt.
[17]R.
Arends,R.
Austein,M.
Larson,D.
Massey,andS.
Rose.
ProtocolModicationsfortheDNSSecurityExtensions.
RFC4035,IETF,2005.
http://www.
ietf.
org/rfc/rfc4035.
txt.
[18]R.
Arends,R.
Austein,M.
Larson,D.
Massey,andS.
Rose.
ResourceRecordsfortheDNSSecurityExten-sions.
RFC4034,IETF,2005.
http://www.
ietf.
org/rfc/rfc4034.
txt.
USENIXAssociation29thUSENIXSecuritySymposium627[19]BSITR-03108-1:SecureE-MailTrans-port.
2016.
https://www.
bsi.
bund.
de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03108/TR03108-1.
pdf.
[20]D.
Crocker,T.
Hansen,andM.
Kucherawy.
Do-mainKeysIdentiedMail(DKIM)Signatures.
RFC6376,IETF,2011.
http://www.
ietf.
org/rfc/rfc6376.
txt.
[21]T.
Chung,D.
Choffnes,andA.
Mislove.
TunnelingforTransparency:ALarge-ScaleAnalysisofEnd-to-EndViolationsintheInternet.
IMC,2016.
[22]T.
Chung,R.
vanRijswijk-Deij,B.
Chandrasekaran,D.
Choffnes,D.
Levin,B.
M.
Maggs,A.
Mislove,andC.
Wilson.
ALongitudinal,End-to-EndViewoftheDNSSECEcosystem.
USENIXSecurity,2017.
[23]T.
Chung,R.
vanRijswijk-Deij,D.
Choffnes,A.
Mis-love,C.
Wilson,D.
Levin,andB.
M.
Maggs.
Under-standingtheRoleofRegistrarsinDNSSECDeployment.
IMC,2017.
[24]Certmgr-MonoCerticateManager.
http://manpages.
ubuntu.
com/manpages/bionic/man1/certmgr.
1.
html.
[25]CheckaDANETLSService.
https://www.
huque.
com/bin/danecheck.
[26]ComcastsupportingoutboundDANE.
https://www.
internetsociety.
org/blog/2017/08/comcast-supporting-outbound-dane/.
[27]V.
DukhovniandW.
Hardaker.
SMTPSecurityviaOpportunisticDNS-BasedAuthenticationofNamedEn-tities(DANE)TransportLayerSecurity(TLS).
RFC7672,IETF,2015.
[28]V.
DukhovniandW.
Hardaker.
TheDNS-BasedAuthen-ticationofNamedEntities(DANE)Protocol:UpdatesandOperationalGuidance.
RFC7671,IETF,2015.
[29]V.
Dukhovni.
NEWSFLASH:DANETLSArecordspublishedforweb.
de.
2016.
https://mailarchive.
ietf.
org/arch/msg/dane/KWMzQLebCeOSgDXhtFAat5NMD60.
[30]Z.
Durumeric,D.
Adrian,A.
Mirian,J.
Kasten,E.
Bursztein,N.
Lidzborski,K.
Thomas,V.
Eranti,M.
Bai-ley,andJ.
A.
Halderman.
NeitherSnowNorRainNorMITM.
.
.
AnEmpiricalAnalysisofEmailDeliverySe-curity.
IMC,2015.
[31]W.
B.
DeVries,R.
vanRijswijk-Deij,P.
-T.
deBoer,andA.
Pras.
PassiveObservationsofaLargeDNSService:2.
5YearsintheLifeofGoogle.
NetworkTrafcMeasurementandAnalysisConference(TMA),2018.
[32]DANESMTPValidator.
https://dane.
sys4.
de/.
[33]DNSSECDeploymentReport.
https://rick.
eng.
br/dnssecstat/.
[34]DNSSECDeploymentStatistics.
https://stats.
dnssec-tools.
org/.
[35]I.
Foster,J.
Larson,M.
Masich,A.
C.
Snoeren,S.
Savage,andK.
Levchenko.
SecuritybyAnyOtherName:OntheEffectivenessofProviderBasedEmailSecurity.
CCS,2015.
[36]H.
HuandG.
Wang.
End-to-EndMeasurementsofEmailSpoongAttacks.
USENIXSecurity,2018.
[37]P.
Hoffman.
SMTPServiceExtensionforSecureSMTPoverTransportLayerSecurity.
IETFRFC3207,IEFT,2002.
[38]P.
HoffmanandJ.
Schlyter.
TheDNS-BasedAuthen-ticationofNamedEntities(DANE)TransportLayerSecurity(TLS)Protocol:TLSA.
RFC6698,IETF,2012.
[39]S.
Huque.
WhitherDANE2019.
https://indico.
dns-oarc.
net/event/31/contributions/707/attachments/682/1125/whither-dane.
pdf.
[40]HSTSPreloadList.
https://opensource.
google.
com/projects/hstspreload.
[41]J.
H.
C.
JacksonandA.
Barth.
HTTPStrictTransportSecurity(HSTS).
RFC6797,IETF,2012.
[42]D.
Kaminsky.
It'stheEndoftheCacheasWeKnowIt.
BlackHat,2008.
https://www.
blackhat.
com/presentations/bh-jp-08/bh-jp-08-Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.
pdf.
[43]D.
Kocieniewski.
AdobeAnnouncesSecurityBreach.
TheNewYorkTimes,2013.
https://www.
nytimes.
com/2013/10/04/technology/adobe-announces-security-breach.
html.
[44]M.
KucherawyandE.
Zwicky.
Domain-basedMessageAuthentication,Reporting,andConformance(DMARC).
RFC7489,IETF,2015.
https://tools.
ietf.
org/html/rfc7489.
[45]S.
Kitterman.
SenderPolicyFramework(SPF)forAu-thorizingUseofDomainsinEmail.
RFC7208,IETF,2014.
https://tools.
ietf.
org/html/rfc7208.
[46]W.
Kumari,O.
Gudmundsson,andG.
Barwood.
Au-tomatingDNSSECDelegationTrustMaintenance.
RFC7344,IETF,2014.
62829thUSENIXSecuritySymposiumUSENIXAssociation[47]A.
Langley.
WhynotDANEinbrowsers.
2015.
https://www.
imperialviolet.
org/2015/01/17/notdane.
html.
[48]B.
Laurie,A.
Langley,andE.
Kasper.
CerticateTrans-parency.
RFC6962,IETF,2013.
http://www.
ietf.
org/rfc/rfc6962.
txt.
[49]T.
Le,R.
V.
Rijswijk-Deij,L.
Allodi,andN.
Zannone.
EconomicIncentivesonDNSSECDeployment:TimetoMovefromQuantitytoQuality.
NOMS,2018.
[50]W.
Lian,E.
Rescorla,H.
Shacham,andStefan.
Mea-suringthePracticalImpactofDNSSECDeployment.
USENIXSecurity,2013.
[51]A.
-M.
E.
Lwinder.
DNSSECDeploymentinSweden:HowDoWeDoItICANN50,2014.
https://london50.
icann.
org/en/schedule/wed-dnssec/presentation-dnssec-deployment-sweden-25jun14-en.
pdf.
[52]Let'sEncrypt.
https://letsencrypt.
org.
[53]D.
Margolis,M.
Risher,G.
Inc.
,B.
Ramakrishnan,O.
Inc.
,A.
Brotman,C.
Inc.
,J.
Jones,andM.
Inc.
SMTPMTAStrictTransportSecurity(MTA-STS).
IETF,2018.
[54]D.
Moore.
DNSserversurvey.
http://mydns.
bboy.
net/survey/.
[55]P.
Mockapetris.
DomainNames-ConceptsandFacili-ties.
RFC1034,IETF,1987.
[56]M.
Shore,R.
Barnes,S.
Huque,andW.
Toorop.
ADANERecordandDNSSECAuthenticationChainExtensionforTLSdraft-ietf-tls-dnssec-chain-extension-07.
IETF,2018.
[57]MassivegrowthinSMTPSTARTTLSdeployment.
https://www.
facebook.
com/notes/protect-the-graph/massive-growth-in-smtp-starttls-deployment/1491049534468526.
[58]MozillapilesonChina'sSSLcertoverlord:Wedon'ttrustyoueither.
http://bit.
ly/1GBPwfG.
[59]NewincentivesforsecuritystandardsDNSSECandDANE.
2019.
https://www.
sidn.
nl/en/news-and-blogs/new-incentives-for-security-standards-dnssec-and-dane.
[60]OpenINTEL.
https://www.
openintel.
nl/.
[61]OpenSSL.
https://www.
openssl.
org/.
[62]I.
Petrov,D.
Peskov,G.
Coard,T.
Chung,D.
Choffnes,D.
Levin,B.
M.
Maggs,A.
Mislove,andC.
Wil-son.
MeasuringtheRapidGrowthofHSTSandHPKPDeployments.
UniversityofMaryland,2017.
http://www.
cs.
umd.
edu/content/measuring-rapid-growth-hsts-and-hpkp-deployments.
[63]Posadis.
http://posadis.
sourceforge.
net/.
[64]Posadis0.
60.
6Release.
http://posadis.
sourceforge.
net/release/041225.
[65]Postx.
http://www.
postfix.
org/.
[66]Z.
RamzanandC.
Wuest.
EmailSpoongAttackstatis-tics.
CEAS,2007.
[67]RegistrarScorecardyieldsgreatresults.
2019.
https://www.
sidn.
nl/en/news-and-blogs/registrar-scorecard-yields-great-results.
[68]Q.
Scheitle,T.
Chung,J.
Hiller,O.
Gasser,J.
Naab,R.
vanRijswijk-Deij,O.
Hohlfeld,R.
Holz,D.
Choffnes,A.
Mislove,andG.
Carle.
AFirstLookatCerticationAuthorityAuthorization(CAA).
CCR,48(2),2018.
[69]R.
SeanandM.
vanderMeer.
ThestateofStart-TLS.
2014.
https://caldav.
os3.
nl/_media/2013-2014/courses/ot/magiel_sean2.
pdf.
[70]S.
SonandV.
Shmatikov.
Thehitchhiker'sguidetoDNScachepoisoning.
SecurityandPrivacyinCommu-nicationNetworks,Springer,2010.
[71]Sendmail.
https://www.
proofpoint.
com/us/open-source-email-solution.
[72]SupportforDNSSEC/DANE/TLSAvalidation.
https://bugzilla.
mozilla.
org/show_bug.
cgiid=1479423.
[73]TheSpamhausProject.
https://www.
spamhaus.
org/.
[74]ThecurrentstateofSMTPSTARTTLSdeployment.
https://www.
facebook.
com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223/.
[75]Trustwavetoescape'deathpenalty'forSSLskeletonkey.
2012.
http://bit.
ly/1RbPlNe.
[76]Unbound.
https://nlnetlabs.
nl/projects/unbound/about/.
[77]Updateonstats2019-10.
2019.
https://mail.
sys4.
de/pipermail/dane-users/2019-November/000534.
html.
[78]A.
Veenman.
SIDNextendsDNSSECdiscountuntilJuly1,2018.
2014.
https://www.
ispam.
nl/archives/38957/sidn-verlengt-dnssec-kortingsregeling-tot-1-juli-2018/.
USENIXAssociation29thUSENIXSecuritySymposium629[79]N.
L.
M.
vanAdrichem,N.
Blenn,A.
R.
Lúa,X.
Wang,M.
Wasif,F.
Fatturrahman,andF.
A.
Kuipers.
Amea-surementstudyofDNSSECmiscongurations.
Sec.
Info.
,4(8),2015.
[80]R.
vanRijswijk-Deij,M.
Jonker,A.
Sperotto,andA.
Pras.
AHigh-Performance,ScalableInfrastructureforLarge-ScaleActiveDNSMeasurements.
IEEEJournalonSelectedAreasinCommunications,34(6),2016.
[81]R.
vanRijswijk-Deij,A.
Sperotto,andA.
Pras.
DNSSECandItsPotentialforDDoSAttacks(ACom-prehensiveMeasurementStudy).
IMC,2014.
[82]P.
WoutersandO.
Gudmundsson.
ManagingDSRecordsfromtheParentviaCDS/CDNSKEY.
RFC8078,IETF,2017.
[83]L.
Zhu,D.
Wessels,A.
Mankin,andJ.
Heidemann.
Mea-suringDANETLSADeployment.
TMA,2015.
[84]djbdns.
http://cr.
yp.
to/djbdns.
html.
ATerminologyInthissection,weprovideaglossaryoftermsandtheirde-nitions.
SimpleMailTransferProtocol(SMTP)isaprotocolforinternetelectronicmailtransmission.
Mailservers(orMailTransferAgent)useSMTPtosendandreceiveemails.
MXrecordisaDNSrecordtospecifywhichmailserversarewillingtoactasamailexchangefortheassociateddomain.
MailTransferAgent(MTA)isasoftwarethattransfersemailmessages;itreceivesincomingemailsfromsourcesanddeliversoutgoingemailstotheirdestinations.
DomainNameSystem(DNS)isahierarchicalandde-centralizednamingsystemforcomputersorotherresourcesconnectedtotheInternet.
Itassociatesvariousresources(e.
g.
,IPaddresses)withdomainnames.
Top-LevelDomains(TLDs)aredomainsundertherootzoneinDNS.
Asecond-leveldomainnamecomesafterthedotsuchas.
comand.
se.
CountryCodeTop-LevelDomain(ccTLD)isoneofthecategoriesofTLD,whichisreservedforacountryorterritoryidentiedwithacountrycodesuchas.
se,.
nl.
GenericTop-LevelDomain(gTLD)isoneofthecate-goriesofTLD,whichisnotcountry-specicbutpairedwithdifferentclassesororganizationssuchas.
com,.
net.
63029thUSENIXSecuritySymposiumUSENIXAssociation