You are on page 1of 241

DRAFT

NIST CYBERSECURITY PRACTICE GUIDE

DOMAIN NAME
SYSTEMS-BASED
ELECTRONIC MAIL
SECURITY
Scott Rose William C. Barker
Santos Jha Chinedum Irrechukwu
Karen Waltermire

NIST SPECIAL PUBLICATION 1800-6


(INCLUDING PARTS A, B, C)

ADDITIONAL CONTENT:
https://nccoe.nist.gov/projects/building_blocks/secured_email
DRAFT
NIST Special Publication 1800-6 NIST Cybersecurity Practice Guide

DOMAIN NAME SYSTEMS-


BASED ELECTRONIC MAIL
SECURITY
1800-6A Scott Rose
Executive Summary Information Technology Laboratory
National Institute of Standards and Technology
1800-6B
Approach, Architecture, and William C. Barker
Security Characteristics
Dakota Consulting
For CIOs, CSOs, and Security Managers Silver Spring, MD
1800-6C Santos Jha
How-To Guides
Chinedum Irrechukwu
For Security Engineers
The MITRE Corporation
McLean, VA

Karen Waltermire
National Cybersecurity Center of Excellence
National Institute of Standards and Technology

November 2016

U.S. Department of Commerce


Penny Pritzker, Secretary

National Institute of Standards and Technology


Willie May, Under Secretary of Commerce for Standards and Technology and Director
DRAFT
DISCLAIMER
Certain commercial entities, equipment, products, or materials may be identified in this
document in order to describe an experimental procedure or concept adequately. Such
identification is not intended to imply recommendation or endorsement by NIST or NCCoE, nor is
it intended to imply that the entities, equipment, products, or materials are necessarily the best
available for the purpose.

National Institute of Standards and Technology Special Publication 1800-6


Natl Inst. Stand. Technol. Spec. Publ. 1800-6, 221 pages (November 2016)
CODEN: NSPUE2

Organizations are encouraged to review all draft publications during public comment periods and
provide feedback. All publications from NISTs National Cybersecurity Center of Excellence are
available at http://nccoe.nist.gov.

For additional information and supplemental materials relating to this document and project,
please see https://nccoe.nist.gov/projects/building_blocks/secured_email.

Comments on this publication may be submitted to: dns-email-nccoe@nist.gov

Public comment period: November 2, 2016 through December 19, 2016

National Cybersecurity Center of Excellence


National Institute of Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899
Mailstop 2002
Email: dns-email-nccoe@nist.gov
DRAFT
NATIONAL CYBERSECURITY CENTER OF EXCELLENCE
The National Cybersecurity Center of Excellence (NCCoE) at the National Institute of Standards
and Technology (NIST) addresses businesses most pressing cybersecurity problems with
practical, standards-based solutions using commercially available technologies. The NCCoE
collaborates with industry, academic, and government experts to build modular, open, end-to-
end reference designs that are broadly applicable and repeatable. The centers work results in
publicly available NIST Cybersecurity Practice Guides, Special Publication Series 1800, that
provide users with the materials lists, configuration files, and other information they need to
adopt a similar approach.
To learn more about the NCCoE, visit http://nccoe.nist.gov. To learn more about NIST, visit
http://www.nist.gov.

NIST CYBERSECURITY PRACTICE GUIDES


NIST Cybersecurity Practice Guides (Special Publication Series 1800) target specific cybersecurity
challenges in the public and private sectors. They are practical, user-friendly guides that facilitate
the adoption of standards-based approaches to cybersecurity. They show members of the
information security community how to implement example solutions that help them align more
easily with relevant standards and best practices.

The documents in this series describe example implementations of cybersecurity practices that
businesses and other organizations may voluntarily adopt. The documents in this series do not
describe regulations or mandatory practices, nor do they carry statutory authority.
DRAFT

DNS-Based Email Security Practice Guide v


PRACTICE GUIDE
NIST SP 1800-6A

1 Domain Name Systems-Based


Electronic Mail Security
3 ExecutiveSummary
4 Bothpublicandprivatesectorbusinessoperationsareheavilyreliantonelectronicmail(email)
5 exchangesbuttheintegrityofthesetransactionsisoftenatrisk,includingfinancialandother
6 proprietaryinformationaswellastheprivacyofemployeesandclients.
7 ProtocolssuchasTransportLayerSecurity(TLS),Secure/MultipurposeInternetMailExtensions(S/
8 MIME),DomainNameSystemSecurityExtensions(DNSSEC),andDomainNameSystem(DNS)
9 AuthenticationofNamedEntities(DANE)existandarecapableofprovidingneededemailsecurity
10 andprivacyprotection.
11 Impedimentssuchastheabsenceofcomprehensiveconfigurationinstructionsforacomposedsetof
12 mailclient,mailtransferagents,andDNSsecuritycomponents,absenceofresourceguidestoeasily
13 implementedsoftwarelibrariesandsoftwareapplicationsforsystemadministrators,andfunctional
14 characteristicsofsecurityapplicationsthatnegativelyimpacttheperformanceofemailsystemshave
15 limitedadoptionoftheseexistingsecurityandprivacyprotocols.
16 Operatingemailsystemswithoutemployingavailablesecurityandprivacyprotocolsincreasesthe
17 opportunitiesforattackerstobreachsensitiveenterpriseinformationbyintroducingfalseaddresses
18 intomailmessages,disruptingsecurecommunicationsignaling,andimprovingtheprobabilityof
19 successfullyinducingenterpriseuserstoopenmaliciousattachments-stillthemostcommonmethod
20 forintroducingmalwareandbreachingenterprisesystems.
21 TheNationalCybersecurityCenterofExcellence(NCCoE)developedasetofexampleDNS-based
22 emailsecuritysolutionsthatorganizationscanusetofacilitateimplementationofsecurityandprivacy
23 protocols,thusreducingthelikelihoodofadatabreach.Thesolutionsetsincludetoolsthatsupport
24 installationandset-upoftrustworthyemailsystems.
25 Thesecuritycharacteristicsinthisguideareinformedbyguidanceandbestpracticesfromstandards
26 organizations.Howthesolutionsetaddressessecurityrequirementsandbestpracticesisaddressed
27 inavolumethatincludesthesecurityapproach,architecture,andsecuritycharacteristics.
28 TheNCCoE'sapproachusesbothopensourceandcommerciallyavailableproductsthatcanbe
29 includedalongsidecurrentmailproductsinexistinginfrastructure.
30 TheexamplesolutionisdescribedinaHowToguidethatshowshowtoimplementasetof
31 standards-based,commerciallyavailablecybersecuritytechnologiesintherealworld.Theguidewill
32 helporganizationsutilizetechnologiestoreducetheriskofuntrustworthyemail,whilesavingthem
33 researchandproofofconceptcosts.
DRAFT
34 THE CHALLENGE
35 Whetherthesecurityservicedesiredisauthenticationofthesourceofanemailmessageorassurance
36 thatthemessagehasnotbeenalteredbyordisclosedtoanunauthorizedparty,organizationsmust
37 employsomecryptographicprotectionmechanism.Economiesofscaleandaneedforuniformsecurity
38 implementationdrivemostenterprisestorelyonmailserversand/orInternetserviceproviders(ISPs)to
39 providesecuritytoallmembersofanenterprise.Manycurrentserver-basedemailsecuritymechanisms
40 arevulnerableto,andhavebeendefeatedby,attacksontheintegrityofthecryptographic
41 implementationsonwhichtheydepend.Theconsequencesofthesevulnerabilitiesfrequentlyinvolve
42 unauthorizedpartiesbeingabletoreadormodifysupposedlysecureinformation,ortouseemailasa
43 vectorforinsertingmalwareintothesysteminordertogainaccesstoenterprisesystemsorinformation.
44 Protocolsexistthatarecapableofprovidingneededemailsecurityandprivacy,butimpedimentssuchas
45 unavailabilityofeasilyimplementedsoftwarelibrariesandsoftwareapplicationscharacteristicsthat
46 complicateoperationofemailsystemshavelimitedadoptionofexistingsecurityandprivacyprotocols.

47 THE SOLUTION
48 TheDomainNameSystem-BasedSecurityforElectronicMail(Email)projecthasproducedaproofof
49 conceptsecurityplatformthatdemonstratestrustworthyemailexchangesacrossorganizational
50 boundaries.Thegoalsoftheprojectincludeauthenticationofmailservers,signingandencryptionof
51 email,andbindingcryptographickeycertificatestotheservers.TheDomainNameSystemSecurity
52 Extension(DNSSEC)protocolisusedtoauthenticateserveraddressesandcertificatesusedforTransport
53 LayerSecurity(TLS)toDNSnames.Thebusinessvalueofthesecurityplatformdemonstratedbythis
54 projectincludesimprovedprivacyandsecurityprotectionforusers'operationsandimprovedsupportfor
55 implementationanduseoftheprotectiontechnologies.Theplatformalsoexpandsthesetofavailable
56 DNSsecurityapplicationsandencourageswiderimplementationofDNSSEC,TLSandS/MIMEtoprotect
57 internetcommunications.

58 Projectdeliverablesinclude:

59 demonstrationprototypesofDNS-basedsecureemailplatforms
60 thispubliclyavailableNISTCybersecurityPracticeGuidethatexplainshowtoemploytheplatform(s)
61 tomeetindustrysecurityandprivacybestpracticesaswellasrequirementsforfederalgovernment
62 agencies
63 platformdocumentationnecessarytoefficientlycomposeaDNS-basedemailsecurityplatformfrom
64 off-the-shelfcomponents
65 recommendationsforeffectiveimplementationinamannerthatisconsistentwithapplicable
66 standardsdocumentation

67 Approach
68 Thesecureemailprojectinvolvescompositionofavarietyofcomponentsthathavebeenprovidedbya
69 numberofdifferenttechnologyproviders,includingMicrosoftCorporation,theInternetSystems
70 Consortium,Secure64,FraunhoferIAO,andStichtingNLnetLaboratories.Eachofthesecollaboratorshas
71 enteredintoaCooperativeResearchandDevelopmentAgreement(CRADA)withNISTtoparticipatein
72 thisconsortiumeffort.Thesecomponentsincludeclientsystems,DNS/DNSSECservices,mailtransfer
73 agents(MTA),andcertificatesources.

74 Wedemonstratehowsecuritycanbesupportedthroughstandards-basedconfigurationandoperation
75 DNSservers,electronicmailapplicationsandMTAsinamannerthatsupportstrustworthyemailbythe
76 organization.
77 Theguide:
2
DRAFT
78 identifiesthesecuritycharacteristicsneededtosufficientlyreducetheriskstoinformationexchanged
79 byemail
80 mapssecuritycharacteristicstostandardsandbestpracticesfromNISTandotherorganizations
81 describesadetailedexamplesolution,alongwithinstructionsforimplementersandsecurity
82 engineersonefficientlyinstalling,configuring,andintegratingthesolutionintoexistingIT
83 infrastructures
84 providesanexamplesolutionthatisoperationallypracticalandevaluatestheperformanceofthe
85 solutioninreal-worldscenarios

86 BENEFITS
87 Ourexamplesolutionhasseveralbenefits,includingthefollowing:

88 reducesrisksothatemployeesareabletoexchangepersonalandenterpriseinformationviaemail
89 withsignificantlyreducedriskofdisclosureorcompromise
90 enablestheuseofexistingsecurityprotocolsmoreefficientlyandwithminimalimpacttoemail
91 serviceperformance
92 integratescapabilitiesintovariousserverandclientITinfrastructureenvironments
93 enhancesvisibilityforsystemadministratorsintoemailsecurityevents,providingforrecognitionof
94 authenticationfailuresthatcouldresultindeviceanddatacompromises
95 implementsbothcommercialandopensourceindustrystandardnetworkandemailsecuritycontrols
96 reducinglongtermcostsanddecreasingtheriskofvendorlock-in
97 canbeextendedtootherenterpriseinformationexchangetechnologiesthataregrowinginuse(e.g.,
98 textmessages,chat)

99 TECHNOLOGY PARTNERS AND COLLABORATORS


100 Thetechnologyvendorswhoparticipatedinthisprojectsubmittedtheircapabilitiesinresponsetoacall
101 intheFederalRegister.CompanieswithrelevantproductswereinvitedtosignaCooperativeResearchand
102 DevelopmentAgreementwithNIST,allowingthemtoparticipateinaconsortiumtobuildthisexample
103 solution.Weworkedwith:

104 MicrosoftCorporation
105 NLnetLaboratories
106 Secure64
107 InternetSystemsConsortium
108 FraunhoferIAO

3
109 SHARE YOUR FEEDBACK
110 YoucangettheguidethroughtheNCCoEwebsite,http://nccoe.nist.gov.Helpusmakeitbetterby
111 sharingyourthoughtswithusasyoureviewtheguide.Ifyouadoptthissolutionforyourown
112 organization,shareyourexperienceandadvicewithus.Werecognizethattechnicalsolutionsalonewill
113 notfullyenablethebenefitsofoursolution,soweencourageorganizationstosharelessonslearnedand
114 bestpracticesfortransformingthebusinessprocessesassociatedwithimplementingit.

115 emaildns-email-nccoe@nist.gov
116 joinourCommunityofInteresttoofferyourinsightsandexpertise;emailusatdns-email-
117 nccoe@nist.gov
118 Tolearnmorebyarrangingademonstrationofthisreferencesolution,contactingusatdns-email-
119 nccoe@nist.gov.

TheNationalCybersecurityCenterofExcellenceattheNationalInstituteof LEARN MORE


StandardsandTechnologyaddressesbusinessesmostpressingcybersecurity http://nccoe.nist.gov
problemswithpractical,standards-basedexamplesolutionsusingcommercially
availabletechnologies.AstheU.S.nationallabforcybersecurity,theNCCoE ARRANGE A DEMONSTRATION
seeksproblemsthatareapplicabletowholesectors,oracrosssectors.The nccoe@nist.gov
center'sworkresultsinpubliclyavailableNISTCybersecurityPracticeGuides
thatprovidemodular,open,end-to-endreferencedesigns. 301-975-0200

4
DRAFT

NIST CYBERSECURITY PRACTICE GUIDE

DOMAIN NAME
SYSTEMS-BASED
ELECTRONIC MAIL
SECURITY
Approach, Architecture, and Security
Characteristics
For CIOs, CISOs, and Security Managers

Scott Rose William Barker Santos Jha


Chinedum Irrechukwu Karen Waltermire

NISTSPECIALPUBLICATION1800-6B
DRAFT

NIST Special Publication 1800-6B NIST Cybersecurity Practice Guide

DOMAIN NAME SYSTEMS-


BASED ELECTRONIC MAIL
SECURITY
1800-6B Scott Rose
Approach, Architecture, and
National Cybersecurity Center of Excellence
Security Characteristics
Information Technology Laboratory
For CIOs, CSOs, and Security
Managers
William C. Barker
Dakota Consulting
Silver Spring, MD

Santos Jha
Chinedum Irrechukwu
The MITRE Corporation
McLean, VA

November2016

U.S. Department of Commerce


Penny Pritzker, Secretary

National Institute of Standards and Technology


Willie May, Under Secretary of Commerce for Standards and Technology and Director
DRAFT

DISCLAIMER
Certaincommercialentities,equipment,products,ormaterialsmaybeidentifiedinthis
documentinordertodescribeanexperimentalprocedureorconceptadequately.Such
identificationisnotintendedtoimplyrecommendationorendorsementbyNISTorNCCoE,nor
isitintendedtoimplythattheentities,equipment,products,ormaterialsarenecessarilythe
bestavailableforthepurpose.

NationalInstituteofStandardsandTechnologySpecialPublication1800-6B
NatlInst.Stand.Technol.Spec.Publ.1800-6B,73pages(November2016)
CODEN:NSPUE2

Organizationsareencouragedtoreviewalldraftpublicationsduringpubliccommentperiods
andprovidefeedback.AllpublicationsfromNISTsNationalCybersecurityCenterofExcellence
areavailableathttp://nccoe.nist.gov.

Commentsonthispublicationmaybesubmittedto:dns-email-nccoe@nist.gov

Publiccommentperiod:November2,2016throughDecember19,2016

NationalCybersecurityCenterofExcellence
NationalInstituteofStandardsandTechnology
100BureauDrive
Gaithersburg,MD20899
Mailstop2002
Email:dns-email-nccoe@nist.gov

DNS-Based Email Security Practice Guide iii


DRAFT

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE


TheNationalCybersecurityCenterofExcellence(NCCoE)attheNationalInstituteofStandards
andTechnology(NIST)addressesbusinessesmostpressingcybersecurityproblemswith
practical,standards-basedsolutionsusingcommerciallyavailabletechnologies.TheNCCoE
collaborateswithindustry,academic,andgovernmentexpertstobuildmodular,open,end-to-
endreferencedesignsthatarebroadlyapplicableandrepeatable.Thecentersworkresultsin
publiclyavailableNISTCybersecurityPracticeGuides,SpecialPublicationSeries1800,that
provideuserswiththematerialslists,configurationfiles,andotherinformationtheyneedto
adoptasimilarapproach.
TolearnmoreabouttheNCCoE,visithttp://nccoe.nist.gov.TolearnmoreaboutNIST,visit
http://www.nist.gov.

NIST CYBERSECURITY PRACTICE GUIDES


NISTCybersecurityPracticeGuides(SpecialPublicationSeries1800)targetspecificcybersecurity
challengesinthepublicandprivatesectors.Theyarepractical,user-friendlyguidesthat
facilitatetheadoptionofstandards-basedapproachestocybersecurity.Theyshowmembersof
theinformationsecuritycommunityhowtoimplementexamplesolutionsthathelpthemalign
moreeasilywithrelevantstandardsandbestpractices.

Thedocumentsinthisseriesdescribeexampleimplementationsofcybersecuritypracticesthat
businessesandotherorganizationsmayvoluntarilyadopt.Thedocumentsinthisseriesdonot
describeregulationsormandatorypractices,nordotheycarrystatutoryauthority.

ABSTRACT
Thisdocumentdescribesasecurityplatformfortrustworthyemailexchangesacross
organizationalboundaries.Theprojectincludesreliableauthenticationofmailservers,digital
signatureandencryptionofemail,andbindingcryptographickeycertificatestosourcesand
servers.Theexamplesolutionsandarchitecturespresentedherearebaseduponstandards-
basedopen-sourceandcommerciallyavailableproducts.

KEYWORDS
authentication;dataintegrity;domainnamesystem;digitalsignature;electronicmail;
encryption;internetaddresses;internetprotocols;namedentities;privacy

ACKNOWLEDGMENTS
Wegratefullyacknowledgethecontributionsofthefollowingindividualsandorganizationsfor
theirgenerouscontributionsofexpertise,time,andproducts.

Name Organization

NateLesser NationalCybersecurityCenterofExcellence

KarenWaltermire NationalCybersecurityCenterofExcellence

DougMontgomery NISTITLAdvancedNetworksTechnologyDivision

DNS-Based Email Security Practice Guide iv


DRAFT

Name Organization

JanetJones MicrosoftCorporation

PaulFox MicrosoftCorporation

JoeGersch Secure64

SakshamManchanda Secure64

BennoOvereinder NLnetLabs

RalphDolmans NLnetLabs

EillemToorop NLnetLabs

BudBruegger FraunhoferIAO

VictoriaRisk InternetSystemsConsortium

EddyWinstead InternetSystemsConsortium

DNS-Based Email Security Practice Guide v


Contents

Contents
1 Summary ............................................................................................................................... 1
1.1 The Challenge...............................................................................................................................3
1.2 The Solution ..................................................................................................................................4
1.3 Benefits .........................................................................................................................................5
1.4 Technology Partners and Collaborators .......................................................................................6
1.5 Feedback ......................................................................................................................................6

2 How to Use This Guide......................................................................................................... 7

3 Introduction........................................................................................................................... 9

4 Approach ............................................................................................................................. 11
4.1 Audience .....................................................................................................................................12
4.2 DNS-Based Electronic Mail Security Project Scope ...................................................................12
4.3 Assumptions ...............................................................................................................................13
4.4 Risk Assessment ........................................................................................................................14
4.5 Technologies...............................................................................................................................32

5 Architecture......................................................................................................................... 35
5.1 Usage Scenarios Supported .......................................................................................................36
5.2 Architectural Overview ................................................................................................................38

6 Outcome .............................................................................................................................. 46
6.1 The Users Experience................................................................................................................46
6.2 The System Administrators Experience .....................................................................................51

7 Evaluation............................................................................................................................ 53
7.1 Assumptions and Limitations ......................................................................................................54
7.2 Testing ........................................................................................................................................54
7.3 Scenarios and Findings ..............................................................................................................57

8 Future Build Considerations ............................................................................................. 60

Appendix A Acronyms ........................................................................................................... 61

Appendix B References ......................................................................................................... 63

Appendix C DNS-Based Email Security Project Mapping to the Framework Core and
Informative References...................................................................................... 67

DNS-Based Email Security Practice Guide vi

DRAFT
Contents

List of Figures
Figure 4.1 DNS-Based Email Security Collaborator Contributions .................................. 33

Figure 5.1 DNS-Based Email Security Deployment Diagram ............................................ 38

Figure 5.2 DNS-Based Email Security Test Set-up ............................................................ 39

Figure 5.3 Fraudulent DNS Address Spoofing Configurations......................................... 41

Figure 5.4 Man-In-The-Middle Event Configurations ......................................................... 42

List of Tables
Table 5.1 Client Systems......................................................................................................43

Table 5.2 Mail Transfer Agents............................................................................................44

Table 5.3 DNS Servers..........................................................................................................44

Table 7.1 Tests Performed ...................................................................................................55

Table C.1 PROTECT (PR)......................................................................................................67

Table C.2 DETECT (DE).........................................................................................................71

Table C.3 RESPOND (RS) .....................................................................................................72

DNS-Based Email Security Practice Guide vii

DRAFT
1 1 Summary
2 1.1 The Challenge...................................................................................................................... 3
3 1.2 The Solution ......................................................................................................................... 4
4 1.3 Benefits ................................................................................................................................ 5
5 1.4 Technology Partners and Collaborators ............................................................................... 6
6 1.5 Feedback ............................................................................................................................. 6
7

DNS-Based Email Security Practice Guide DRAFT 1


Chapter 1. Summary

8 ThisNationalInstituteofStandardsandTechnology(NIST)CybersecurityPracticeGuide
9 addressesthechallengeofprovidingdigitalsignaturetechnologiestoprovideauthentication
10 andintegrityprotectionforelectronicmail(email)onanend-to-endbasis,andconfidentiality
11 protectionforemailintransitbetweenorganizations.Itimplementsandfollows
12 recommendationsofNISTSpecialPublication800-177(SP800-177),Trustworthy Email.
13 DetailedprotocolinformationandimplementationdetailsareprovidedinSP800-177.Domain
14 NameSystem1protectionfeaturesareconsistentwithSP800-81-2,Secure Domain Name
15 System (DNS) Deployment Guide.
16 TheNISTSpecialPublication1800-6seriesofdocumentscontain:
17 rationaleforanddescriptionsofaDomainNameSystem-Based(DNS-Based)ElectronicMail
18 (Email)Securityplatformthatpermitstrustworthyemailexchangesacrossorganizational
19 boundariesand
20 aseriesofHow-ToGuides,includinginstructionsforinstallationandconfigurationofthe
21 necessaryservices,thatshowsystemadministratorsandsecurityengineershowtoachieve
22 similaroutcomes
23 Thesolutionsandarchitecturespresentedarebuiltuponstandards-based,commercially
24 availableproducts.Thesesolutionscanbeusedbyanyorganizationdeployingemailservices
25 thatiswillingtoimplementcertificate-basedcryptographickeymanagementandDNSSecurity
26 Extensions(DNSSEC)2.Interoperablesolutionsareprovidedthatareavailablefromdifferent
27 typesofsources(e.g.,bothcommercialandopensourceproducts)andfunctionindifferent
28 operatingsystemsenvironments.
29 ThissummarysectiondescribesthechallengeaddressedbythisVolumeB(Approach,
30 Architecture, and Security Characteristics);describesthesolutiondemonstratedtoaddressthe
31 challenge;benefitsofthedemonstratedsolution;liststhetechnologypartnersthat
32 participatedinbuilding,demonstrating,anddocumentingthesolution;andexplainshowto
33 providefeedbackonthisguide.Section2,HowtoUseThisGuideexplainshoweachvolumeof
34 theguidemaybeusedbybusinessdecisionmakers,programmanagers,andInformation
35 Technology(IT)professionalssuchassystemsadministrators;andSection3,Introduction
36 providesahigh-levelprojectoverview.Section4,Approachprovidesamoredetailedtreatment
37 ofthescopeoftheproject,describestheassumptionsonwhichsecurityplatformdevelopment
38 wasbased,describestheriskassessmentthatinformedplatformdevelopment,anddescribes
39 thetechnologiesandcomponentsthatwereprovidedbyindustrycollaboratorstoenable
40 platformdevelopment.Section5,Architecturedescribestheusagescenariossupportedby
41 projectsecurityplatforms,includingCybersecurityFramework3functionssupportedbyeach
42 collaborator-contributedcomponent.Section6,Outcomedescribesanychangesinusers'mail
43 processingexperienceimposedbytheadditionalsecurityfunctionality,andsummarizes
44 changestosystemsadministrators'experienceswithrespecttointegratingthenewcapabilities
45 intotheirsystemsandinsystemsoperationsandmaintenance.Section7,Evaluation
46 summarizesthetestsequencesthatwereemployedtodemonstratesecurityplatformservices,
47 theCybersecurityFrameworkfunctionstowhicheachtestsequenceisrelevant,theNISTSP
48 800-53-4controlsthatappliedtothefunctionsbeingdemonstrated,andanoverviewof

1.RFC1591,Domain Name System Structure and Delegation


2.RFC4033,DNS Security Introduction and Requirements
3.Framework for Improving Critical Infrastructure Cybersecurity,Version1.0,NationalInstitute
of Standards and Technology February 12, 2014 http://www.nist.gov/cyberframework/up-
load/cybersecurity-framework-021214.pdf

DNS-Based Email Security Practice Guide DRAFT 2


Chapter 1. Summary

49 platformperformanceineachofthetwoapplicationsscenariosdemonstrated.Section8,
50 FutureBuildConsiderationsisabrieftreatmentofotherapplicationsthatmightbeexploredin
51 thefutureindemonstratingtheadvantagesofbroaderDNSsecurityadoption.Appendicesare
52 providedforacronyms,references,andamappingoftheDNS-BasedEmailSecurityprojectto
53 theCybersecurityFrameworkCore4andinformativesecurityreferencescitedinthe
54 CybersecurityFrameworkCore.

55 1.1 The Challenge


56 Bothprivateindustryandthegovernmentareconcernedaboutemailsecurityandtheuseof
57 emailasanattackvectorforcybercrime.Businessoperationsareheavilyreliantonemail
58 exchangesandneedtoprotecttheconfidentialityofbusinessinformation,theintegrityof
59 transactions,andprivacyofindividuals.Cryptographicservicesareusedtoauthenticatethe
60 sourceofemailmessages,protectagainstundetectedunauthorizedalterationofmessagesin
61 transit,andmaintainmessageconfidentiality.Efficiencyandpoliciessupportrelianceonmail
62 serverstoprovidecryptographicprotectionforemailratherthanonend-to-endsecurity
63 operatedbyindividualusers.However,organizationsneedtoprotecttheirserver-basedemail
64 securitymechanismsagainstintrusionandman-in-the-middleattacksduringautomated
65 cryptographicservicenegotiation.IntheabsenceofanappropriatecombinationofDNSSEC
66 andcertificate-basedprotections,anyoftheseattackscanresultindisclosureormodification
67 ofinformationbyunauthorizedthirdparties.Theattackscanalsoenableanattackertoposeas
68 oneofthepartiestoanemailexchangeandsendemailthatcontainslinkstomalware-ridden
69 websites.Ifothercontentinafraudulentmessagesuccessfullymotivatestheusertoclickon
70 thelinkortheuser'ssystemisconfiguredtoautomaticallyfollowsomelinksordownload
71 contentotherthantext,themalwarewillinfecttheuser'ssystem.Inclusionoflinkstomalware
72 isamajorfactorinmostconfirmeddatabreaches.Consequencesofsuchbreachescanrange
73 fromexposureofsensitiveorprivateinformation,toenablingfraudulentactivitybythe
74 attackerposingasthevictimizeduser,todisablingordestroyingtheuser'ssystem-orthatofthe
75 user'sparentorganization.Beyondavoidanceofnegativeconsequencestousers,improved
76 emailsecuritycanalsoserveasamarketingdiscriminatorforemailserviceproviders.
77 ImplementationofDNSSECandDNS-BasedAuthenticationOfNamedEntities(DANE)5have
78 beenimpededinthepastbyashortageofeasilyusedsoftwarelibrariesandbythefactthat
79 mostavailableemailapplicationsoftheprotocolsrespondtoabsentorincorrectdigital
80 signaturesbyneitherpermittingdeliveryofthemessagenoralertingthemailserverthat
81 failuretodeliverisbasedonaDNSSECissue.Theconsequenceofthefirstimpedimentisthat,
82 unlessforcedbypolicytodoso,ITorganizationsdeferDNSSEC/DANEimplementationpending
83 availabilityofmorematuresoftwarelibraries.Theconsequenceifthesecondisthat,when
84 DNSSECandDANEareturnedon,mailserversexperiencesevereservicedegradationorcrashes
85 duetolargenumbersofretransmissionattempts.

4.http://www.nist.gov/cyberframework/
5.RFC6698,The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security
Protocol:TLSA

DNS-Based Email Security Practice Guide DRAFT 3


Chapter 1. Summary

86 1.2 The Solution


87 DNSSECprotectsagainstunauthorizedmodificationstodomainnameinformationtoprevent
88 connectiontospoofedormalicioushosts.TheNCCoEinitiatedacollaborativeprojectwith
89 industrypartnerstodevelopaproof-of-conceptsecurityplatformthatprovidestrustworthy
90 mailserver-to-mailserveremailexchangesacrossorganizationalboundaries.Products
91 comprisingthesecurityplatformincludeclientmailuseragents(MUAs)6,DNSservers
92 (authoritativeandcaching/recursive)7,mailtransferagents,(MTAs)8,andX.509cryptographic
93 keycertificatesources(componentsandservices).Thenetworkinfrastructureproductsare
94 similartothosefoundineveryenterpriseandusedtoperformbasicITfunctionsandhandle
95 email.ThecertificateutilitiesareneededtoproduceX.509certificates9formailserversand
96 enduserstosupportTransportLayerSecurity(TLS)10andSecure/MultipurposeInternetMail
97 Extensions(S/MIME)11.ThisinitialprojectfocusesonSimpleMailTransferProtocol(SMTP)12
98 overTLSandS/MIME.
99 TheDNS-basedsecureemailbuildingblockprojecthasdemonstratedasecurityplatform,
100 consistentwithSP800-177,thatprovidestrustworthyemailexchangesacrossorganizational
101 boundaries.Theprojectincludesauthenticationofmailservers,digitallysigningandencrypting
102 email13,andbindingcryptographickeycertificatestotheservers.Thesoftwarelibraryissue
103 wasaddressedinSP1800-6cbyprovidinginstallationandconfigurationinstructionsforusing
104 andmaintainingexistingsoftwarelibraries(includinginstallationsupportapplications).Atthe
105 sametime,inclusionofsoftwaredevelopersandvendorsinthedevelopmentand
106 demonstrationprocessrevealedsoftwareandimplementationguidanceshortcomingsthat
107 havebeencorrected.

6.AccordingtoNISTSpecialPublication(SP)800-177,anMUAisasoftwarecomponent(orweb
interface)thatallowsanendusertocomposeandsendmessagesandtooneormorerecipients.
AnMUAtransmitsnewmessagestoaserverforfurtherprocessing(eitherfinaldeliveryortrans-
fertoanotherserver).
7.AccordingtoSection3.2ofSP800-177,therearetwomaintypesofnameservers:authorita-
tivenameserversandcachingnameservers.Thetermauthoritativeiswithrespecttoazone.If
anameserverisanauthoritativesourceforDNSresourcerecordsforaparticularzone(orzones)
ofDNSaddresses,itiscalledanauthoritative name serverforthatzone(orzones).Anauthori-
tativenameserverforazoneprovidesresponsestonameresolutionqueriesforresourcesfor
thatzone,usingtherecordsinitsownzonefile.Acaching name server(alsocalledaresolv-
ing/recursivenameserver),bycontrast,providesresponseseitherthroughaseriesofqueriesto
authoritativenameserversinthehierarchyofdomainsfoundinthenameresolutionqueryor
fromacacheofresponsesbuiltbyusingpreviousqueries.
8.AlsoaccordingtoSP800-177,mailistransmitted,inastoreandforwardfashion,acrossnet-
worksviaMailTransferAgents(MTAs).MTAscommunicateusingtheSimpleMailTransferPro-
tocol(SMTP)describedbelowandactasbothclientandserver,dependingonthesituation.
9.RFC5280,Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile
10.RFC5246,The Transport Layer Security (TLS) Protocol Version 1.2
11. RFC 5751, Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message
Specification
12.RFC5321,Simple Mail Transfer Protocol
13.Cryptographicprotection,whilevoluntaryfortheprivatesectorhas,foranumberofappli-
cationsbeenmademandatoryforfederalgovernmentagencies(seeManagingInformationasa
StrategicResource,OMBCircularA-130)

DNS-Based Email Security Practice Guide DRAFT 4


Chapter 1. Summary

108 1.3 Benefits


109 Sectorsacrossindustries,aswellasthefederalgovernment,areconcernedaboutemail
110 securityandtheuseofemailasanattackvector.14Bothpublicandprivatesectorbusiness
111 operationsareheavilyreliantonemailexchanges.Theneedtoprotecttheintegrityof
112 transactionscontainingfinancialandotherproprietaryinformationandtoprotecttheprivacy
113 ofemployeesandclientsareamongthefactorsthatmotivateorganizationstosecuretheir
114 email.Whethertheservicedesiredisauthenticationofthesourceofanemailmessage,
115 assurancethatthemessagehasnotbeenalteredbyanunauthorizedparty,ormessage
116 confidentiality,cryptographicfunctionsareusuallyemployed.Economiesofscaleandaneed
117 foruniformimplementationdrivemostenterprisestorelyonmailserverstoprovidesecurityto
118 themembersofanenterpriseratherthansecurityimplementedandoperatedbyindividual
119 users.Manyserver-basedemailsecuritymechanismsarevulnerabletoattacksinvolving:
120 fakedorfraudulentdigitalcertificates
121 otherwiseinvalidcertificates
122 failuretoactuallyinvokeasecurityprocessasaresultofconnectiontoorthrougha
123 fraudulentserver
124 Evenifthereareprotectionsinplace,someattackshavebeenabletosubvertemail
125 communicationbyattackingtheunderlyingsupportprotocolssuchasDNS.Attackerscanspoof
126 DNSresponsestoredirectemailserversandalteremaildelivery.DNSSECwasdevelopedto
127 preventthis.DNSSECprotectsagainstunauthorizedmodificationstonetworkmanagement
128 informationandhostIPaddresses.DNSSECcanalsobeusedtoprovideanalternative
129 publicationandtrustinfrastructureforservicecertificatesusingtheDNS-basedAuthentication
130 ofNamedEntities(DANE)resourcerecords.
131 Thebusinessvalueofthesecurityplatformthatresultsfromthisprojectincludesimproved
132 privacyandsecurityprotectionsforusers'communication,aswellasimprovedmanagementof
133 DNSandemailsecurityoperations.Addressingthesoftwarelibraryandmessage
134 retransmissionissues,respectively,reducesthedifficultyandcostofinstallingandmaintaining
135 DNSSECandDANE.Mitigatingthemajorcauseofsystemerrorsresultingfromfaulty
136 deploymentofDNSSECandDANEwillencourageuseofcapabilitiesalreadypresentinmany
137 emailsystems.Demonstrationandpublicationoftheseimprovementsencourageswider
138 implementationoftheprotocolsthatprovideInternetuserswithconfidencethatemailhas
139 beenprotectedandreachestheintendedreceiverinasecuremanner.Thedemonstrated
140 platformaddressesthreeofthefivecoreFunctionalCategoriesintheFrameworkforImproving
141 CriticalInfrastructureCybersecurityandmanyrequirementsofrelevantsecuritystandardsand
142 guidelines.Implementationoftheplatformwillbeincreasinglyimportantasamarket
143 discriminatoraspublicawarenessofemailsecurityandprivacyissuesgrows.

14.HowCybercrimeExploitsDigitalCertificates,InfosecInstitute,General Security,July28,
2014,http://resources.infosecinstitute.com/cybercrime-exploits-digital-certificates

DNS-Based Email Security Practice Guide DRAFT 5


Chapter 1. Summary

144 1.4 Technology Partners and Collaborators


145 Thetechnologyvendorswhoparticipatedinthisbuildsubmittedtheircapabilitiesinresponse
146 toanoticeintheFederalRegister.Companieswithrelevantproductswereinvitedtosigna
147 CooperativeResearchandDevelopmentAgreement(CRADA)withNIST,allowingthemto
148 participateinaconsortiumtobuildthisexamplesolution.Weworkedwith:
149 MicrosoftCorporation
150 NLnetLaboratories
151 Secure64
152 InternetSystemsConsortium
153 FraunhoferIAO

154 1.5 Feedback


155 Youcanimprovethisguidebycontributingfeedback.Asyoureviewandadoptthissolutionfor
156 yourownorganization,weaskyouandyourcolleaguestoshareyourexperienceandadvice
157 withus.
158 emaildns-email-nccoe@nist.gov
159 joinourCommunityofInteresttoofferyourinsightsandexpertise;emailusat
160 dns-email-nccoe@nist.gov
161 Orlearnmorebyarrangingademonstrationofthisexamplesolutionbycontactingusat
162 dns-email-nccoe@nist.gov

DNS-Based Email Security Practice Guide DRAFT 6


1 2 How to Use This Guide
2 ThisNISTCybersecurityPracticeGuidedemonstratesastandards-basedreferencedesignand
3 providesuserswiththeinformationtheyneedtoreplicatethisapproachtoemailsecurity.The
4 referencedesignismodularandcanbedeployedinwholeorinparts.
5 Thisguidecontainsthreevolumes:
6 NISTSP1800-6a:ExecutiveSummary
7 NIST SP 1800-6b: Approach, Architecture, and Security Characteristics - what we built and
8 why (you are here)
9 NISTSP1800-6c:How-ToGuides-instructionsforbuildingtheexamplesolution
10 Dependingonyourroleinyourorganization,youmightusethisguideindifferentways:
11 Business decision makers, including chief security and technology officerswillbeinterestedin
12 theExecutiveSummary(NISTSP1800-6a),whichdescribesthe:
13 challengesenterprisesfaceinimplementingandoperatingatrustworthyemailservice
14 examplesolutionbuiltattheNCCoE
15 benefitsofadoptingtheexamplesolution
16 Technology or security program managerswhoareconcernedwithhowtoidentify,
17 understand,assess,andmitigateriskwillbeinterestedinthispartoftheguide.NISTSP1800-
18 6bdescribeswhatwedidandwhy.Section4.4,RiskAssessmentwillbeofparticularinterest.
19 Thissectionprovidesadescriptionoftheriskanalysisweperformedandmapsthesecurity
20 servicesprovidedbythisexamplesolutiontotheFramework for Improving Critical
21 Infrastructure Cybersecurityandrelevantsecuritystandardsandguidelines.
22 YoumightsharetheExecutiveSummary,NISTSP1800-6a,withyourleadershipteammembers
23 tohelpthemunderstandtheimportanceofadoptingstandards-basedaccessmanagement
24 approachestoprotectyourorganization'sdigitalassets.
25 IT professionalswhowanttoimplementanapproachlikethiswillfindthewholepracticeguide
26 useful.YoucanusetheHow-ToGuides,NISTSP1800-6c,toreplicateallorpartsofthebuild
27 createdinourlab.TheHow-Toguideprovidesspecificproductinstallation,configuration,and
28 integrationinstructionsforimplementingtheexamplesolution.Wedonotre-createthe
29 productmanufacturers'documentation,whichisgenerallywidelyavailable.Rather,weshow
30 howweincorporatedtheproductstogetherinourenvironmenttocreateanexamplesolution.
31 ThisguideassumesthatITprofessionalshaveexperienceimplementingsecurityproducts
32 withinenterprises.Whilewehaveusedasuiteofcommercialandopensourcesoftware
33 productstoaddressthischallenge,thisguidedoesnotendorsetheseparticularproducts.Your
34 organizationcanadoptthissolutionoronethatadherestotheseguidelinesinwhole,oryou
35 canusethisguideasastartingpointfortailoringandimplementingpartsofasolutionthat
36 wouldsupportthedeploymentofantrustworthyemailsystemandthecorrespondingbusiness

DNS-Based Email Security Practice Guide DRAFT 7


Chapter 2. How to Use This Guide

37 processes.Yourorganization'ssecurityexpertsshouldidentifytheproductsthatwillbest
38 integratewithyourexistingtoolsandITsysteminfrastructure.Wehopeyouwillseekproducts
39 thatarecongruentwithapplicablestandardsandbestpractices.Section4.5,Technologies,lists
40 theproductsweusedandmapsthemtothecybersecuritycontrolsprovidedbythisreference
41 solution.
42 ANISTCybersecurityPracticeGuidedoesnotdescribethesolution,butapossiblesolution.
43 Thisisadraftguide.Weseekfeedbackonitscontentsandwelcomeyourinput.Comments,
44 suggestions,andsuccessstorieswillimprovesubsequentversionsofthisguide.Please
45 contributeyourthoughtstodns-email-nccoe@nist.gov.

DNS-Based Email Security Practice Guide DRAFT 8


1 3 Introduction
2 Asstatedinsection1.1,bothpublicandprivatesectorbusinessoperationsareheavilyreliant
3 onelectronicmail(email)exchanges.Theyneedtoprotecttheintegrityoftransactionsthat
4 mayincludefinancialandotherproprietaryinformation.Theprivacyofemployeesandclients
5 isalsoafactorthatmotivatesorganizationstosecuretheiremailsystems.Securityservices
6 suchastheauthenticationofthesourceofanemailmessage,assurancethatthemessagehas
7 notbeenalteredbyanunauthorizedparty,andconfidentialityofmessagecontentsrequirethe
8 useofcryptographicfunctions.Aneedforuniformsecurityimplementationdrivesmost
9 enterprisestorelyonmailserverstoprovidesecuritytothemembersofanenterpriserather
10 thanrelyonenduserstoimplementasecuritypolicyontheirown.However,mostcurrent
11 server-basedemailsecuritymechanismsarevulnerableto,andhavebeendefeatedby,attacks
12 ontheintegrityofthecryptographicimplementationsonwhichtheydepend.The
13 consequencesfrequentlyinvolveunauthorizedpartiesbeingabletoreadormodifysupposedly
14 secureinformation,ortouseemailasavectorforinsertingmalwareintotheenterprise.
15 Improvedemailsecuritycanhelpprotectorganizationsandindividualsagainstthese
16 consequencesandalsoserveasamarketingdiscriminatorforemailserviceprovidersaswellas
17 improvethetrustworthinessofenterpriseemailexchanges.
18 DomainNameSystemSecurityExtensionsfortheDomainNameSystemaretechnical
19 mechanismsemployedbydomainownerstoprotectagainstunauthorizedmodificationto
20 networkmanagementinformation.DANEisaprotocolthatsecurelyassociatesdomainnames
21 withcryptographiccertificatesandrelatedsecurityinformationsothatclientscanbetter
22 authenticatenetworkservices.Inspiteofthedangersoffailuretoauthenticatetheidentitiesof
23 networkdevices,adoptionofDNSSEChasbeenslow.DemonstrationofDANE-supported
24 applicationssuchasreliablysecureemailmaysupportincreaseduserdemandfordomain
25 namesystemsecurity.Follow-onprojectsmightincludeHTTPS,IOT,IPSECkeysinDNS,andDNS
26 servicediscovery.
27 TheDNS-BasedEmailSecurityprojectdemonstratedproofofconceptsecurityplatforms
28 composedofofftheshelfcomponentsthatprovidestrustworthymailserver-to-mailserver
29 emailexchangesacrossorganizationalboundaries.TheDANEprotocolisusedtoauthenticate
30 serversandcertificatesintworolesintheDNS-BasedSecurityforEmailProject:(1)Bybinding
31 theX.509certificatesusedforTransportLayerSecurity(TLS)toDNSSECsignednamesformail
32 server-to-mailservercommunication;and(2)bybindingtheX.509certificatesusedfor
33 Secure/MultipurposeInternetMailExtensions(S/MIME)toemailaddressesencodedasDNS
34 names.ThesebindingssupporttrustintheuseofS/MIMEcertificatesintheend-to-endemail
35 communication.Theresultingplatformsencryptemailtrafficbetweenserversandallow
36 individualemailuserstoobtainotherusers'certificatesinordertovalidatesignedemailor
37 sendencryptedemail.1Theprojectwillincludeanemailsendingpolicyconsistentwithastated
38 privacypolicythatcanbeparsedbyreceivingserverssothatreceivingserverscanapplythe
39 correctsecuritychecks.

1.S/MIMEcandothisnow,butDANEmakesiteasiertoactuallyuse.

DNS-Based Email Security Practice Guide DRAFT 9


Chapter 3. Introduction

40 Documentationoftheresultingplatformincludesstatementsofthesecurityandprivacy
41 policiesandstandards(e.g.,ExecutiveOrders,NISTstandardsandguidelines,IETFRFCs).This
42 alsoincludestechnicalspecificationsforhardwareandsoftware,implementation
43 requirements,andamappingofimplementationrequirementstotheapplicablepolicies,
44 standards,andbestpractices.
45 Thesecureemailprojecthasinvolvedcompositionofavarietyofcomponentsthatwere
46 providedbyseveraldifferenttechnologyproviders.ComponentsincludeMUAs,DNSSEC
47 capableDNSservers,MTAs,andcryptographiccertificatesources.Thesecomponentsareused
48 togenerateandhostDNSSECsignedzonesandTLSenabledmailservices.
49 ThisprojectresultedindemonstrationofsupporttoMUAsandMTAsbyfourDNS-basedsecure
50 emailplatformsandthispubliclyavailableNISTCybersecurityPracticeGuidethatexplainshow
51 toemploythesuite(s)tomeetsecurityandprivacyrequirements.Thisguidealsoprovides
52 platformdocumentationnecessarytocomposeaDNS-basedemailsecurityplatformfromoff
53 theshelfcomponentsthatcomposedtheprototypeplatforms.

DNS-Based Email Security Practice Guide DRAFT 10


1 4 Approach
2 4.1 Audience ............................................................................................................................ 12
3 4.2 DNS-Based Electronic Mail Security Project Scope .......................................................... 12
4 4.3 Assumptions....................................................................................................................... 13
5 4.4 Risk Assessment................................................................................................................ 14
6 4.5 Technologies ...................................................................................................................... 32
7

DNS-Based Email Security Practice Guide DRAFT 11


Chapter 4. Approach

8 4.1 Audience
9 Thisguideisintendedforindividualsresponsibleforimplementingsecuritysolutionsin
10 organizations'ITsupportactivities.CurrentITsystems,particularlyintheprivatesectoroften
11 lackintegrityprotectionfordomainnameservicesandelectronicmail.Theplatforms
12 demonstratedbytheDNS-BasedEmailSecurityproject,andtheimplementationinformation
13 providedinthesePracticeGuidespermitintegrationofDNSandemailintegrityservicesand
14 emailconfidentialityserviceswithminimumchangestoexistinginfrastructureorimpactto
15 serviceoperations.Thetechnicalcomponentswillappealtosystemadministrators,IT
16 managers,ITsecuritymanagers,andothersdirectlyinvolvedinthesecureandsafeoperation
17 ofthebusinessITnetworks.

18 4.2 DNS-Based Electronic Mail Security Project Scope


19 TheDNS-BasedElectronicMailSecurityprojectisconsistentwithNISTSP800-177and
20 demonstratestheuseofoff-the-shelfTransportLayerSecurity(TLS),DomainNameSystem
21 (DNS)SecurityExtensions(DNSSEC),andDNS-basedAuthenticationofNamedEntities(DANE)
22 componentstoachievetrustworthyelectronicmail(email)objectivesinamannerthatis
23 consistentwithNISTSP800-81-2.

24 4.2.1 Transport Layer Security (TLS)


25 TheprojectusesTLStoprotectconfidentialityofemailmessagesexchangedbetweenmail
26 servers.TLSreliesonkeysstoredasX.509digitalcertificates.Thesecertificatescanbeusedto
27 authenticatetheidentity(server,domainororganization)ofthecertificateowner.

28 4.2.2 Domain Name System (DNS) Security Extensions (DNSSEC)


29 TheprojectusesDNSSECtoauthenticateandprotecttheintegrityofDNSdata.DNSSECuses
30 digitalsignaturesoverDNSdatatopreventanattackerfromtamperingwithorspoofingDNS
31 responses.MailserversusetheDNStofindthedestinationofemailaswellasstoringother
32 artifactsnecessaryforemailsecurity(seebelow).

33 4.2.3 DNS-based Authentication of Named Entities (DANE)


34 TheprojectusesDANE,aprotocolthatsecurelyassociatesdomainnameswithcryptographic
35 certificatesandrelatedsecurityinformationsothattheycan'tbefraudulentlymodifiedor
36 replacedtobreachsecurity.DNSSECbindstheX.509certificatesusedforTLStoDNS.

37 4.2.4 Binding X.509 Certificates with DANE


38 TheprojectalsousesDANEtobindtheX.509certificatesusedforS/MIMEtoemailaddresses
39 encodedasDNSnamesverifiedbyDNSSEC.

DNS-Based Email Security Practice Guide DRAFT 12


Chapter 4. Approach

40 4.2.5 Demonstration of Digital Signature and Encryption of Email


41 Theprojectdemonstratessendingencryptedmessagesbetweenemailsystemsresidentin
42 differentDNSdomains,wheretheemailexchangesbetweentwoorganizations'emailservers
43 arecarriedoverTLS,andtheTLSkeymanagementisprotectedbyDANEandDNSSEC.Signed
44 emailwassentbetweenamessageoriginatorandareceivingpartyusingenduserapplications
45 (end-to-end)indifferentDNSdomains,wheretheemailexchangesbetweenorganizations
46 werecarriedoverTLS,theemailmessagesweresignedandverifiedwithS/MIMEonthe
47 end-users'clientdevices,andtheS/MIMEkeymanagementwasprotectedbyDANEand
48 DNSSEC.Inaddition,theprojectdemonstratedthattheuseofDNSSECandDANEblocksan
49 attemptbyafraudulentmailservertoposeasthelegitimatemailserverforthereceiverofthe
50 email.

51 4.2.6 Demonstration of End-to-end Digital Signature of Mail


52 Theproject'sdigitalsignaturedemonstrationincludedsendingS/MIMEsignedemailbetweena
53 messageoriginatorandareceivingpartyusingenduserapplicationsindifferentDNSdomains.
54 TheemailexchangesbetweenorganizationsarecarriedoverTLS,theemailmessagesare
55 signedandverifiedwithS/MIMEontheend-users'clientdevices,andtheS/MIMEcertificates
56 arestoredintheDNSandprotectedbyDNSSEC.Thisaspectoftheprojectalsodemonstrated
57 thatuseofDANEblocksanattemptbyafraudulentactortoposeastheemailoriginators.

58 4.3 Assumptions

59 4.3.1 Security and Performance


60 TheemailplatformsandDNSservicesdemonstratedprovideemailintegrityandconfidentiality
61 protection.Anunderlyingassumptionisthatthebenefitsofusingthedemonstratedplatforms
62 outweighanyadditionalperformancerisksthatmaybeintroduced.Thesecurityofexisting
63 systemsandnetworksisoutofscopeforthisproject.Akeyassumptionisthatallpotential
64 adoptersofoneofthedemonstratedbuilds,oranyoftheircomponents,alreadyhaveinplace
65 somedegreeofnetworksecurity.Therefore,wefocusedonwhatpotentialnewsystem
66 vulnerabilitieswerebeingintroducedtoendusersiftheyimplementthissolution.Thegoalof
67 thissolutionistonotintroduceadditionalvulnerabilitiesintoexistingsystems,butthereis
68 alwaysinherentriskwhenaddingsystemsandaddingnewfeaturesintoanexistingsystem.

69 4.3.2 Modularity
70 ThisassumptionisbasedononeoftheNCCoEcoreoperatingtenets.Itisreasonablyassumed
71 thatorganizationsalreadyhavemailclientandserversystemsinplace.Ourphilosophyisthata
72 combinationofcertaincomponentsorasinglecomponentcanimproveemailsecurityforan
73 organization;theymaynotneedtoremoveorreplacemostexistinginfrastructure.Thisguide
74 providesacompletetop-to-bottomsolutionandisalsointendedtoprovidevariousoptions
75 basedonneed.

DNS-Based Email Security Practice Guide DRAFT 13


Chapter 4. Approach

76 4.3.3 Technical Implementation


77 Thispracticeguideiswrittenfromahow-toperspective,anditsforemostpurposeisto
78 providedetailsonhowtoinstall,configure,andintegratethecomponents.TheNCCoEassumes
79 thatanorganizationhasthetechnicalresourcestoimplementallorpartsofthebuild,orhas
80 accesstocompaniesthatcanperformtheimplementationonitsbehalf.

81 4.3.4 Operating System and Virtual Machine Environments


82 ThisprojectwasconductedprimarilyinaVmwarevcenterserverversion6.0.0Build3018523
83 virtualmachineenvironment.Itisassumedthatuserorganizationswillbeabletoinstallthe
84 demonstratedapplicationsincloud-hostedVMs,localvirtualmachineorlocalnativeserver
85 clientenvironments.ThisprojectusesCentos7,WindowsServer2012R2,andWindows10
86 operatingsystems.Operatingsystemswerechosenbasedontherequirementsofthesoftware.
87 TheDNS-basedsecureemailbuildingblockprojectassumes,andisdependentupon,the
88 availabilityofoff-theshelfinformationsecuritytechnology.Particularproductsandexpertise
89 onwhichtheprojectisdependentincludethoseforMUAs,MTAs,DNSservers(authoritative
90 andrecursive)andX.509certificateutilities.

91 4.4 Risk Assessment


92 AccordingtoNISTSP800-30,Risk Management Guide for Information Technology Systems,
93 Riskisthenetnegativeimpactoftheexerciseofavulnerability,consideringboththe
94 probabilityandtheimpactofoccurrence.Riskmanagementistheprocessofidentifyingrisk,
95 assessingrisk,andtakingstepstoreducerisktoanacceptablelevel.TheNCCoErecommends
96 thatanydiscussionofriskmanagement,particularlyattheenterpriselevel,beginwitha
97 comprehensivereviewofNIST800-37,Guide for Applying the Risk Management Framework to
98 Federal Information Systems.Theriskmanagementframework(RMF)anditsassociated
99 referencesforidentifiedsecurityfunctionsprovidesabaselinefororganizingandrelatingto
100 organizationalobjectivesof:
101 1. theriskstoelectronicmailandthenetworksittransits
102 2. thesecurityrequirementstobemetinorderforthesecurityplatformtoreducetheserisks
103 Whilethisguidedoesnotpresentafullriskassessment,itdoeshighlightthebroadcategories
104 ofthreatsandvulnerabilitiesassociatedwithelectronicmail.

105 4.4.1 Threats


106 Belowarecommonthreatsassociatedwithelectronicmail:
107 useofemailasavehicleforintroducingmalware
108 useofemailasadeliverymechanismforsocialengineeringattacks
109 theftordestructionofdatacommunicatedbyemailand/oritsattachmentsduetolossor
110 unauthorized/unintentionaldisposalofmessages
111 lossofprivacyresultingfromunauthorizedaccesstoemail

DNS-Based Email Security Practice Guide DRAFT 14


Chapter 4. Approach

112 unauthorizedmodificationofinformationcommunicatedbyemail
113 maliciousfraudulentcreationofmessagesorattachmentsattributedtothirdparties

114 4.4.2 Vulnerabilities


115 Vulnerabilitiesarecommonlyassociatedwithmailclientapplications,mailtransfer
116 applications,andnetworkapplicationsthatareemployedincreation,delivery,andreadingof
117 email.However,vulnerabilitiescanbeexploitedatalllevelsintheinformationstack.For
118 up-to-dateinformationregardingvulnerabilities,thisguiderecommendsthatsecurity
119 professionalsleveragetheNationalVulnerabilityDatabase(NVD).TheNVDistheU.S.
120 governmentrepositoryofstandards-basedvulnerabilitymanagementdata
121 [https://nvd.nist.gov].

122 4.4.2.1 Client System Vulnerabilities


123 Organizationsaregettingbetteratprotectingnetworkperimeters,andcompanieswithmature
124 securityprogramsusuallyallowonlycertainportsthroughthefirewallandharden
125 Internet-accessibleserverstominimizetheattacksurface.Asaresult,attackersarepaying
126 closerattentiontoclient-sidevulnerabilitiesoninternalworkstations.Theseclient-side
127 vulnerabilitiesoftenareassimpleasunpatchedsoftwareonadesktoporlaptop.Mostclient
128 systemsrunatleastoneoperatingsystemandquiteafewapplications.Listingspecific
129 vulnerabilitiesforeachisbeyondthescopeofthisguide,butacurrentlistofvulnerabilitiesand
130 informationregardingpatchesareavailablefromNIST'sNationalVulnerabilityDatabase
131 referencedabove.Dependingonthenatureofavulnerableapplication,anattackermayexploit
132 itusingaspeciallycraftedemailattachmentorbyconvincingtheusertovisitamaliciousWeb
133 site.Webbrowsersarecommontargets.OtherattractivetargetsincludeAdobeAcrobat1,
134 MacromediaFlash2,QuickTime3andJavaRuntimeEnvironment4.

135 4.4.2.2 Mail Server Vulnerabilities


136 Mailservershavemanyofthesamevulnerabilitiesasclientsystems,butwealsoneedtobe
137 awareofprotocol-basedvulnerabilitiesinvolvingaccesstovalidlistsofemailaddresses,
138 vulnerabilitiestorelayexploitsformalwareinsertion,vulnerabilitiestoemailheader
139 disclosures,andvulnerabilitiestovirusesandworms.InthecaseofSMTP,onewaythat
140 attackerscanverifywhethere-mailaccountsexistonaserverissimplytotelnettotheserver
141 onport25andruntheVRFYcommand.5TheVRFYcommandmakesaservercheckwhethera
142 specificuserIDexists.Spammersoftenautomatethismethodtoperformadirectory harvest
143 attack,whichisawayofgleaningvalide-mailaddressesfromaserverordomainforhackersto

1. See https://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-497/Adobe-Ac-
robat-Reader.html.
2.See
https://www.cvedetails.com/vulnerability-list/vendor_id-73/product_id-1950/version_id-8545
/Macromedia-Flash-Player-6.0.29.0.html.
3.Seehttps://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7117.
4.Seehttps://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-4903.
5.AnumberofISPsnowblockport25.

DNS-Based Email Security Practice Guide DRAFT 15


Chapter 4. Approach

144 use.Scriptingthisattackcantestthousandsofe-mailaddresscombinations.TheSMTP
145 commandEXPNmayallowattackerstoverifywhatmailinglistsexistonaserver.Yetanother
146 waytocapturevalide-mailaddressesistouseapplicationssuchastheHarvestertoglean
147 addressesviaGoogleandothersearchengines.InMicrosoftExchange,accountenumerationis
148 notgenerallyanissue.
149 InenvironmentsotherthanMicrosoftExchange,accountenumerationisnotgenerallyanissue.
150 Insuchenvironments,thebestsolutionforpreventingthistypeofe-mailaccountenumeration
151 dependsonwhetheryouneedtoenablecommandslikeSMTP'sVRFYandEXPNcommands.In
152 general,itisimportanttoensurethatcompanye-mailaddressesarenotpostedontheweb.
153 ProtocolslikeSMTPrelayletuserssende-mailsthroughexternalservers.Opene-mailrelays
154 aren'ttheproblemtheyusedtobe,buttheycanstillbesourcesofvulnerabilities.Spammers
155 andhackerscanuseane-mailservertosendspamormalwarethroughe-mailundertheguise
156 oftheunsuspectingopen-relayowner.
157 Inthecaseofemailheaderdisclosures,e-mailserversconfiguredwithtypicaldefaults,maybe
158 vulnerabletodivulginginformationsuchasinternalIPaddressesofe-mailclients,software
159 versionsofclientande-mailserversalongwiththeirvulnerabilities,orhostnamesthatcan
160 divulgenetworknamingconventions
161 Emailsystemsareregularlytargetedbymalwaresuchasvirusesandworms.Itisnecessaryto
162 verifythatmailservers'antivirussoftwareisactuallyworking.Asinthecaseofclientsystems
163 vulnerabilities,NIST'sNationalVulnerabilityDatabase(https://nvd.nist.gov)isafrequently
164 updatedsourceofvulnerabilitiesthataffectmailservers.

165 4.4.2.3 Network Vulnerabilities


166 TheMITRECorporation'sCommonVulnerabilityEnumeration(CVE)listsmorethan85,000
167 vulnerabilitiesthatcanaffectwebservers,SystemQueryLanguage(SQL)servers,DNSservers,
168 firewalls,routers,andothernetworkcomponents(seehttps://cve.mitre.org).Theseinclude
169 vulnerabilitiestodenialofservice,codeexecution,overflow,cross-sitescripting,directory
170 traversal,processbypass,unauthorizedgainingofinformation,SQLinjection,fileinclusion,
171 memorycorruption,cross-siterequestforgery,andhttpresponsesplitting.Manyofthe
172 vulnerabilitiesareoperatingsystemorapplications-based.Othersareprotocolbased(e.g.
173 vulnerabilitiesinherentinIP6,TLS,DNS7,BGP8,SMTPandothernetworkprotocols).Asinthe
174 caseofclientsystemsvulnerabilities,NIST'sNationalVulnerabilityDatabase
175 (https://nvd.nist.gov)isafrequentlyupdatedsourceofvulnerabilitiesthataffectnetwork
176 servers.

177 4.4.3 Risk


178 Risksareexaminedfromthepointofviewofconsequencesofvulnerabilitiesbeingexploited.
179 Someexamplesoftheseconsequencesincludelegalliability,consequencesoffailuretocomply
180 withregulations,confidentialitybreaches,lossofproductivity,anddamagetoorganizational
181 reputation.

6.RFC791,Internet Protocol
7.RFC1034,Domain Names - Concepts And Facilities
8.RFC4271,A Border Gateway Protocol 4 (BGP-4)

DNS-Based Email Security Practice Guide DRAFT 16


Chapter 4. Approach

182 Newandexistingregulationsareforceorganizationstokeeparecordoftheiremailsandto
183 protecttheiremployeeandcustomerprivacy.Forexample,theHealthInsurancePortability
184 andAccountabilityAct(HIPAA)requireshealthcareinstitutionstokeeparecordoftheir
185 emailcommunicationsandsecureconfidentialityofinformation.InthenewIRSregulation
186 Circular230,theIRSrequirestaxadvisorstoaddanemaildisclaimertoanyemailsincluding
187 taxadvice,expresslystatingthattheopinioncannotberelieduponforpenaltypurposes.
188 TheU.S.SecuritiesandExchangeCommissionandGramm-Leach-BlileyActimposesimilar
189 dutiesonfinancialinstitutions.Steeppenaltiescanapplytothoseorganizationsthatdonot
190 complywiththeirindustry'sregulations.Inacaselastingfrom2000until2005,a
191 well-knownfinancialinstitutionwasrecentlyforcedtopay20milliondollarsinpenaltiesby
192 theSecuritiesandExchangeCommissionfornotdiligentlysearchingforemailback-up
193 tapesandover-writingmultipleback-uptapes.
194 Mostconfidentialitybreachesoccurfromwithinthecompany.Thesebreachescanbe
195 accidental,buttheycanalsobeintentional.
196 Withrespecttolegalliability,organizationsaregenerallyheldresponsibleforallthe
197 informationtransmittedonorfromtheirsystem,soinappropriateemailssentonthe
198 companynetworkcanresultinmulti-milliondollarpenalties.
199 Employeessendingpersonalemailsandsiftingthroughspammailcancausemajorlossof
200 productivity.9
201 Evenjustabadlywrittenemail,oranemailcontainingunprofessionalremarkswillcause
202 therecipienttogainabadimpressionofthecompanythatthesenderisrepresenting.
203 Fraudulentemailattributabletoanorganizationcandofarmoredamagetoan
204 organization'sreputation,bothintermsoftheresponseelicitedandintermsoflossof
205 confidenceinthecybersecurityreliabilityoftheorganization
206 Anumberofcybersecurityactionsarerecommendedtoreducetheserisks.TheFramework
207 CoreidentifiedinNIST'sFramework for Improving Critical Infrastructure Cybersecurityisasetof
208 cybersecurityactivities,desiredoutcomes,andapplicablereferencesthatarecommonacross
209 criticalinfrastructuresectors.TheCorepresentsindustrystandards,guidelines,andpracticesin
210 amannerthatallowsforcommunicationofcybersecurityactivitiesandoutcomesacrossthe
211 organizationfromtheexecutiveleveltotheimplementation/operationslevel.TheFramework
212 CoreconsistsoffiveconcurrentandcontinuousFunctions:Identify,Protect,Detect,Respond,
213 andRecover.Whenconsideredtogether,thesefunctionsprovideahigh-level,strategicviewof
214 thelifecycleofanorganization'smanagementofcybersecurityrisk.

9.CurrentSPAMfilteringsolutionsconsistofsomesortoffilteringatthenetworkorthePClevel,
andtheydon'trevealthedetailsofthesenderwithoutlookingupthesource.Ittakessomework
fortherecipient.Thiswillalwaysputusonestepbehindthebadguys.DNSprovidestheneces-
saryInternet-widescalingandDNSSECachievesthisauthentication.

DNS-Based Email Security Practice Guide DRAFT 17


Chapter 4. Approach

215 4.4.4 Cybersecurity Framework Functions, Categories, and Subcategories


216 Addressed by the DNS-Based Email Security Project
217 TheFramework for Improving Critical Infrastructure Cybersecurity10(CybersecurityFramework)
218 providesacommonlanguageforunderstanding,managing,andexpressingcybersecurityrisk
219 bothinternallyandexternally.Itcanbeusedtohelpidentifyandprioritizeactionsforreducing
220 cybersecurityrisk,anditisatoolforaligningpolicy,business,andtechnologicalapproachesto
221 managingthatrisk.Itcanbeusedtomanagecybersecurityriskacrossentireorganizationsorit
222 canbefocusedonthedeliveryofcriticalserviceswithinanorganization.Differenttypesof
223 entities-includingsectorcoordinatingstructures,associations,andorganizations-canusethe
224 CybersecurityFrameworkfordifferentpurposes,includingthecreationofcommonProfiles.As
225 statedabove,theFrameworkCoreprovidesasetofactivitiestoachievespecificcybersecurity
226 outcomes,andreferencesexamplesofguidancetoachievethoseoutcomes.TheCoreisnota
227 checklistofactionstoperform.Itpresentskeycybersecurityoutcomesidentifiedbyindustryas
228 helpfulinmanagingcybersecurityrisk.TheCorecomprisesfourelements:Functions,
229 Categories,Subcategories,andInformativeReferences.
230 Functionsorganizebasiccybersecurityactivitiesattheirhighestlevel.TheseFunctionsare
231 Identify,Protect,Detect,Respond,andRecover.Theyaidanorganizationinexpressingits
232 managementofcybersecurityriskbyorganizinginformation,enablingriskmanagement
233 decisions,addressingthreats,andimprovingbylearningfrompreviousactivities.The
234 Functionsalsoalignwithexistingmethodologiesforincidentmanagementandhelpshow
235 theimpactofinvestmentsincybersecurity.Forexample,investmentsinplanningand
236 exercisessupporttimelyresponseandrecoveryactions,resultinginreducedimpacttothe
237 deliveryofservices.
238 CategoriesarethesubdivisionsofaFunctionintogroupsofcybersecurityoutcomesclosely
239 tiedtoprogrammaticneedsandparticularactivities.ExamplesofCategoriesincludeAsset
240 Management,AccessControl,andDetectionProcesses.
241 SubcategoriesfurtherdivideaCategoryintospecificoutcomesoftechnicaland/or
242 managementactivities.Theyprovideasetofresultsthat,whilenotexhaustive,help
243 supportachievementoftheoutcomesineachCategory.ExamplesofSubcategoriesinclude
244 Externalinformationsystemsarecataloged,Data-at-restisprotected,and
245 Notificationsfromdetectionsystemsareinvestigated.
246 Informative Referencesarespecificsectionsofstandards,guidelines,andpractices
247 commonamongcriticalinfrastructuresectorsthatillustrateamethodtoachievethe
248 outcomesassociatedwitheachSubcategory.TheInformativeReferencespresentedinthe
249 FrameworkCoreareillustrativeandnotexhaustive.Theyarebaseduponcross-sector
250 guidancemostfrequentlyreferencedduringtheFrameworkdevelopmentprocess.
251 TheDNS-BasedE-MailSecurityBuildingBlockprojectsupportstheCybersecurityFramework's
252 Protect,Detect,andRespondFunctions.Applicabilitytospecificcategories,subcategories,and
253 functionsisdescribedinthefollowingparagraphs.

10.Framework for Improving Critical Infrastructure Cybersecurity,Version1.0,NationalInstitute


of Standards and Technology February 12, 2014. http://www.nist.gov/cyberframework/up-
load/cybersecurity-framework-021214.pdf

DNS-Based Email Security Practice Guide DRAFT 18


Chapter 4. Approach

254 4.4.4.1 Protect


255 TheProtectfunctiondevelopsandimplementstheappropriatesafeguardsneededtoensure
256 deliveryofcriticalinfrastructureservices.Thisfunctionsupportstheabilitytolimitorcontain
257 theimpactofapotentialcybersecurityevent.ExamplesofoutcomeCategorieswithinthis
258 FunctionthatareaddressedbytheDNS-BasedE-MailSecurityprojectinclude:AccessControl
259 andProtectiveTechnology.
260 1. Access Control (PR.AC)
261 TheProtectFunction'sAccessControlCategorysupportsanoutcomeinwhichaccessto
262 assetsandassociatedfacilitiesislimitedtoauthorizedusers,processes,ordevices,andto
263 authorizedactivitiesandtransactions.
264 a. PR.AC-1
265 ThePR.AC-1subcategoryunderAccessControlsupportsidentitiesandcredentials
266 beingmanagedforauthorizeddevicesandusers.Thesecurityplatformresultingfrom
267 theDNS-BasedE-MailSecurityprojectsupportseffectivemanagementofthe
268 credentialsassociatedwiththeaddressesfromwhichelectronicmailpurportedly
269 originatesandtheintegrityoftheuseridentitiesassociatedwiththeelectronicmail.
270 TheoriginaldesignoftheDomainNameSystem(DNS)didnotincludesecurity;instead,
271 itwasdesignedtobeascalabledistributedsystem.DNSSECandDANEattempttoadd
272 security,whilemaintainingbackwardcompatibilitywiththeexistingDNS.DNSSECwas
273 designedtoprotectapplications(andcachingresolversservingthoseapplications)from
274 usingforgedormanipulatedDNSdata.AllanswersfromDNSSECprotectedzonesare
275 cryptographicallysigned(i.e.,digitalsignatureoverDNSdata).Bycheckingthedigital
276 signature,aDNSresolverisabletodeterminewhethertheinformationisauthentic(i.e.
277 unmodifiedandcomplete)andisservedonanauthoritativeDNSserver.While
278 protectingIPaddressesistheimmediateconcernformanyusers,DNSSECcanprotect
279 anydatapublishedintheDNS,includingtextrecordsormailexchange(MX)records,
280 andcanbeusedtobootstrapothersecuritysystemsthatpublishreferencesto
281 cryptographiccertificatesstoredintheDNS.
282 AllDNSSECresponsescontainsignedDNSdata.DNSSECsignaturevalidationallowsthe
283 useofpotentiallyuntrustworthypartiesif(forexample)themailserverisusinga
284 self-signedcertificate.Theprotocolpermitconfigurationofsystemstoacceptmessages
285 whetherornottheyaredigitallysigned.Thesecurityplatformdevelopedunderthe
286 DNS-BasedE-MailSecurityprojectpermitselectronicmailclientsandtransferagentsto
287 beconfiguredsystemstosendemailmessagestoonlyserverwhoseDNSentriesare
288 digitallysigned.Attheclientsystemslevel(e.g.,Outlook,Postfix,Thunderbird),digital
289 signatureofthemailmessagesthemselvescanalsobeappliedonuser-to-userbasis.In
290 theuser-to-usercase,thesignatureprovidesassuranceoftheintegrityoftheidentityof
291 thesenderratherthanjusttheidentityoftheDNSzone(s)associatedwiththesender.
292 b. PR.AC-3
293 ThePR.AC-3subcategoryunderAccessControlsupportsmanagementofremote
294 access.Oneofthemostcommonvectorsformalwareinfectionisauserclickingona
295 linkthatisincludedinane-mailmessagefromaspoofedsource.Clickingonthelink
296 enablesremoteaccesstotheuser'ssystem,andpreventingdeliveryofe-mailfrom
297 bogussourcesrepresentsamanagementcontrolprotectingagainstremoteaccessby
298 maliciousentities.TheDNS-BasedE-MailSecurityproject'sdemonstratedsecurity

DNS-Based Email Security Practice Guide DRAFT 19


Chapter 4. Approach

299 platformcanbeusedasabasisforacceptingorrefusingelectronicmailbasedon
300 authenticateddatastoredintheDNS.Thishasanaddedbenefitofsupporting
301 protectionagainstremoteaccessbasedonotherthane-mailfunctions.
302 c. PR.AC-5
303 ThePR.AC-5subcategoryunderAccessControlsupportsprotectionofnetworkintegrity
304 byincorporatingnetworksegregationwhereappropriate.TheDNS-BasedE-Mail
305 Securityprojectdoesnotemployspecificallynetworksegregationprinciples.However,
306 itdoessupportnetworkintegritybyprovidingoperationallyfeasiblemechanismsfor
307 preventingconnectionsormessagedeliverytosourcesthatdonotimplementa
308 specifiedsetofDNSsecurityextensions.Rigorousadherencetoaminimumsecurity
309 configurationcanenforceeffectiveisolationofanetworkfromentitiesthatdonot
310 conformtothenetwork'ssecurityrequirements.
311 2. Data Security (PR.DS)
312 TheProtectFunction'sDataSecurityCategorysupportsanoutcomeinwhichinformation
313 andrecords(data)aremanagedconsistentwiththeorganization'sriskstrategytoprotect
314 theconfidentiality,integrity,andavailabilityofinformation.TheDNS-BasedE-MailSecurity
315 projectdemonstratesacapabilitytoprovidesourceandcontentintegrityprotectionby
316 employingdigitalsignatureofmessagesandconfidentialityprotectionbyencrypting
317 messages.
318 a. PR.DS-1
319 ThePR.DS-1subcategoryunderDataSecuritysupportsprotectionofdataatrest.The
320 user-to-userdigitalsignaturecapabilitydemonstratedbytheDNS-BasedE-MailSecurity
321 projectcanprovideanabilitytoverifythesourceandcontentintegrityofstorede-mail
322 messageswherethedigitalsignatureisstoredwiththerestofthemessage.This
323 supportsintegrityprotectionfordata-at-rest.
324 b. PR.DS-2
325 ThePR.DS-2subcategoryunderDataSecuritysupportsprotectionofdataintransit.In
326 additiontouser-to-userdigitalsignatureofe-mail,theDNS-BasedE-MailSecurity
327 projectdemonstratesacapabilitytoprovidesourceandcontentintegrityprotectionto
328 data-in-transitbyemployingserver-to-serverconfidentialityprotectionto
329 data-in-transitbyemployingserver-to-serverencryption.
330 c. PR.DS-6
331 ThePR.DS-6subcategoryunderDataSecuritysupportsuseofintegritychecking
332 mechanismstoverifysoftware,firmware,andinformationintegrity.Thedigital
333 signatureofe-maildemonstratedbytheDNS-BasedE-MailSecurityproject'ssecurity
334 platformsupportsautomaticintegritycheckingofinformationcommunicatedine-mail
335 messages.DNSSECandDANEprotecttheintegrityofaddressinformation.
336 3. Protective Technology (PR.PT)
337 TheProtectFunction'sProtectiveTechnologyCategory'sgoalistoensurethesecurityand
338 resilienceofsystemsandassetsbymanagingatechnicalsecuritysolutionconsistentwith
339 relatedpolicies,procedures,andagreements.

DNS-Based Email Security Practice Guide DRAFT 20


Chapter 4. Approach

340 a. PR-PT-4
341 ThePR.PT-4subcategoryunderProtectiveTechnologysupportsprotectionof
342 communicationsandcontrolnetworks.TheDNS-BasedE-MailSecurityproject
343 demonstratesacapabilitytoprovidesourceandcontentintegrityprotectionby
344 employingdigitalsignatureofcommunicationsandconfidentialityprotectionby
345 encryptingcommunications.ThesupportdemonstratedforuseofDNSSECandDANE
346 protocolsalsosupportcommunicationsandcontrolnetworkintegritybydemonstrating
347 operationallyfeasiblemechanismsforrefusingconnectionstoormessagedeliveryfrom
348 sourcesthatdonotimplementaspecifiedsetofDNSsecurityextensions.Rigorous
349 adherencetoaminimumsecurityconfigurationcanbeusetoenforceisolation
350 networksfromentitiesthatdonotconformtothenetwork'ssecurityrequirements.

351 4.4.4.2 Detect


352 TheDetectFunctiondevelopsandimplementstheappropriateactivitiesneededtoidentifyina
353 timelymannertheoccurrenceofacybersecurityevent.Examplesofoutcomecategorieswithin
354 thisfunctionthatareaddressedbytheDNS-BasedE-MailSecurityprojectincludeSecurity
355 ContinuousMonitoringandDetectionProcesses.
356 1. Security Continuous Monitoring (DE.CM)
357 TheSecurityContinuousMonitoringCategorysupportsanoutcomeinwhichinformation
358 systemandassetsaremonitoredatdiscreteintervalstoidentifycybersecurityeventsand
359 toverifytheeffectivenessofprotectivemeasures.Whilenotaclassicexampleof
360 continuousmonitoring,theDNS-BasedE-MailSecurityplatformhastheabilityto
361 automaticallycheckallDNSresponsesforcorrectdigitalsignatures.
362 a. DE.CM-1
363 TheDE.CM-1subcategoryunderSecurityContinuousMonitoringsupportsmonitoring
364 ofnetworkstodetectpotentialcybersecurityevents.Whilenotaclassicexampleof
365 continuousmonitoring,thedemonstratedcapabilityoftheDNS-BasedE-MailSecurity
366 platformtoautomaticallycheckallinboundDNSresponsesforvaliddigitalsignatures
367 permitsidentificationofattemptstospoofsystemsusingbogusDNSdata.Automatic
368 signingandsignaturevalidationfore-mailpermitscontinuouscheckingforfalsesender
369 identitiesandmodificationofmessagecontent.
370 b. DE.CM-6
371 TheDE.CM-6subcategoryunderSecurityContinuousMonitoringsupportsmonitoring
372 ofexternalserviceprovideractivitytodetectpotentialcybersecurityevents.Whilenot
373 aclassicexampleofcontinuousmonitoring,thedemonstratedcapabilityofthe
374 DNS-BasedE-MailSecurityplatformtoautomaticallycheckallinboundDNSresponses
375 forvaliddigitalpermitsdetectionandpreventionofattemptsbyinvalidservice
376 providers(e.g.,bogusCertificateAuthoritiesorMailTransferAgents)tospoofusers'
377 systems(includingman-in-the-middleattacks).
378 2. Detection Processes (DE.DP)
379 TheDetectionProcessesCategorysupportsanoutcomeinwhichdetectionprocessesand
380 proceduresaremaintainedandtestedtoensuretimelyandadequateawarenessof
381 anomalousevents.

DNS-Based Email Security Practice Guide DRAFT 21


Chapter 4. Approach

382 a. DE.DP-4
383 TheDE.DP-4subcategoryunderDetectionProcessessupportseventcommunicationof
384 detectioninformationtoappropriateparties.OneoftheshortcomingsofmostDNSSEC
385 andDANEmechanismsisthattheyabortdeliveryofmessagesfromsourceswhose
386 DNSSECsignaturechecksfailstovalidateanddonotprovideanyindicationthatfailure
387 isduetoaninvalidsignature.Thisusuallyresultsinnumerousretransmissionsand
388 consequentperformancedegradationorpossiblecrashes.TheDNS-BasedE-Mail
389 SecurityplatformincludesinitsDNSresolversnotificationsofDNSsignaturefailuresto
390 mailagentsinordertopreventconsequentperformancedegradation.This
391 communicationofdetectioninformationhasthepotentialtomitigateoneofthe
392 primaryimpedimentstoprivatesectoradoptionofDNSSEC.

393 4.4.4.3 Respond


394 TheRespondFunctiondevelopsandimplementstheappropriateactivitiestotakeaction
395 regardingadetectedcybersecurityevent.ThisFunctionsupportstheabilitytocontainthe
396 impactofapotentialcybersecurityevent.Examplesofoutcomecategorieswithinthisfunction
397 thatareaddressedbytheDNS-BasedE-MailSecurityprojectinclude:ResponsePlanning,
398 Communications,andMitigation.
399 1. Response Planning (RS.RP)
400 TheResponsePlanningCategorysupportsanoutcomeinwhichresponseprocessesand
401 proceduresareexecutedandmaintained,toensuretimelyresponsetodetected
402 cybersecurityevents.
403 a. RS.RP-1
404 TheRS.RP-1subcategoryunderResponsePlanningsupportsexecutionofaresponse
405 planduringorafteranevent.InclusionofDNSandemailsecurityinsecurityplanning
406 forsystemsconnectedtotheInternetwillnecessarilyincluderesponsestodetectionof
407 invaliddigitalsignaturesthatincludesecurityflaggingofconnectionsandmessages,
408 and/orrefusingconnectionsanddeliveryofmessages.Concurrentwithdetectionof
409 validationfailuredetection,theseresponsesaredemonstratedbytheDNS-Based
410 E-MailSecurityplatform.
411 2. Communications (RS.CO)
412 TheRS.CO-2subcategoryunderCommunicationssupportsreportingofeventsconsistent
413 withestablishedcriteria.AsstatedunderDE.DP-4,oneoftheshortcomingsofmostDNSSEC
414 andDANEmechanismsisthattheyabortdeliveryofmessagestodestinationswhose
415 DNSSECsignaturechecksfailbutdonotprovideanyindicationthatthefailureisduetoan
416 invalidsignature.Inordertopreventconsequentperformancedegradation,theDNS-Based
417 E-MailSecurityplatformincludesinitsDNSresolverconfigurationnotificationsofDNSSEC
418 signaturefailurestomailagents(i.e.configurationtologrelevantDNSSECissues).This
419 communicationofdetectioninformationhasthepotentialtomitigateoneoftheprimary
420 impedimentstoprivatesectoradoptionofDNSSEC.Italsoprovidesamechanismthatcan
421 beexploitedtoprovidetoexternalstakeholdersinformationinvolvingfailuresofDNSSEC
422 signaturechecks.
423 a. RS.CO-2
424 TheRS.CO-2subcategoryunderCommunicationssupportsreportingofevents
425 consistentwithestablishedcriteria.AsstatedunderDE.DP-4,oneoftheshortcomings

DNS-Based Email Security Practice Guide DRAFT 22


Chapter 4. Approach

426 ofmostDNSSECandDANEmechanismsisthattheyabortdeliveryofmessagesto
427 destinationswhoseDNSSECsignaturechecksfailbutdonotprovideanyindicationthat
428 thefailureisduetoaninvalidsignature.Inordertopreventconsequentperformance
429 degradation,theDNS-BasedE-MailSecurityplatformincludesinitsDNSresolvers
430 notificationsofDNSSECsignaturefailurestomailagents.Thiscommunicationof
431 detectioninformationhasthepotentialtomitigateoneoftheprimaryimpedimentsto
432 privatesectoradoptionofDNSSEC.Italsoprovidesamechanismthatcanbeexploited
433 toprovidetoexternalstakeholdersinformationinvolvingfailuresofDNSSECsignature
434 checks.
435 3. Mitigation (RS.MI)
436 a. RS.MI-1
437 TheRS.MI-1subcategoryunderMitigationsupportscontainmentofincidents.Inthe
438 caseofincidentsthatcompromisetheintegrityofnetworksystemsthroughwhich
439 electronicmailisrouted,theeffectsofthecompromisecanbelimitedtothoselocal
440 systemsanddevicesthathavenotimplementedtheintegrityandconfidentiality
441 mechanismsdemonstratedbytheDNS-BasedE-MailSecurityplatform.11
442 b. RS.MI-2
443 TheRS.MI-2subcategoryunderMitigationsupportsmitigationofincidents.The
444 DNS-BasedE-MailSecurityprojectdemonstratesuser-to-userdigitalsignatureof
445 messages.Retentionoftheirdigitalsignatureswithstoredmessagespermitslater
446 determinationofwhetherthemessageshavebeenmodifiedinstorage.Thiscanbea
447 mitigatingfactorinthecaseofincidentsthatinvolveintroductionoffraudulent
448 informationintoelectronicmailrecords.Theproject'sdemonstrationof
449 server-to-serverencryptionprovidesconfidentialityprotectionfordata-in-transit.This
450 confidentialityprotectioncanserveasamitigatingfactorinthecaseofincidents
451 involvingunauthorizedaccesstomessagescapturedbynetworkdevicesthatsit
452 betweenthesender'sandrecipient'smailservers.

453 4.4.5 Cybersecurity References Directly Tied to those Cybersecurity


454 Framework Categories and Subcategories Addressed by the
455 DNS-Based Email Security Project
456 ThefollowingsecurityreferenceswerefollowedinacceptingcomponentsfortheDNS-Based
457 EmailSecurityplatform,designingtheplatform,conductingdemonstrationsoftheplatform,
458 anddocumentingtheplatform.TheFrameworkfunctions,categories,andsubcategories
459 addressedbythesereferencesarelistedforeachreference.Whilemanyofthereferenceswere
460 writtenasstandardsandguidelinestobeappliedtofederalgovernmentagencies,their
461 recommendationsmayalsobeappliedintheprivatesectorasbestpracticesthatsupport
462 CybersecurityFrameworkfunctionalcategoriesandsubcategories.Thosesubcategories
463 addressedbytheDNS-BasedEmailSecurityplatformareinboldface.

11.Notethat,ifasystemissubverted,alotofassumedsecuritygoesoutthewindow.Asubvert-
edsendingMTAcouldstillbeseenasvalidbyreceiversforexample.

DNS-Based Email Security Practice Guide DRAFT 23


Chapter 4. Approach

464 1. Security Requirements for Cryptographic Modules,FederalInformationProcessingStandard


465 (FIPS),FIPS140-2,May2001.http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
466 FIPS140-2providesastandardthatisrequiredtobeusedbyFederalorganizationswhen
467 theseorganizationsspecifythatcryptographic-basedsecuritysystemsbeusedtoprovide
468 protectionforsensitiveorvaluabledata.Protectionofacryptographicmodulewithina
469 securitysystemisnecessarytomaintaintheconfidentialityandintegrityoftheinformation
470 protectedbythemodule.AllcryptographiccomponentsemployedbytheFederal
471 governmentoutsidethenationalsecuritycommunity,includingNCCoEsecurityplatforms
472 thatemploycryptography,mustconformtoFIPS140-2.Thisstandardspecifiesthesecurity
473 requirementsthatwillbesatisfiedbyacryptographicmodule.Thestandardprovidesfour
474 increasingqualitativelevelsofsecurityintendedtocoverawiderangeofpotential
475 applicationsandenvironments.Thesecurityrequirementscoverareasrelatedtothesecure
476 designandimplementationofacryptographicmodule.Theseareasincludecryptographic
477 modulespecification;cryptographicmoduleportsandinterfaces;roles,services,and
478 authentication;finitestatemodel;physicalsecurity;operationalenvironment;
479 cryptographickeymanagement;electromagneticinterference/electromagnetic
480 compatibility(EMI/EMC);self-tests;designassurance;andmitigationofotherattacks.
481 WithinthecontextoftheCybersecurityFramework,FIPS140-2providesstandardsfor
482 Protectiontobeprovidedbycryptographicmodules(PR.AC-2,PR.AC-3,PR.AC-4,
483 PR.DS-1,PR.DS-2,PR.DS-5,PR.DS-6,PR.IP-3,andPR.PT-4)andDetectionoffailuresor
484 otherexceptionconditionsthatmightaffecttheprotectionaffordedtosystemsby
485 cryptographicmodules(DE.CM-1,DE.CM-2,andDM.DP-3).
486 2. Guide for Applying the Risk Management Framework to Federal Information Systems: A
487 security Lifecycle Approach,NISTSpecialPublication,SP800-37Rev.1,JointTaskForce
488 TransformationInitiative;February2010withupdatesasofJune5,2014.
489 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf
490 SP800-37Rev.1providesguidelinesforapplyingtheRiskManagementFramework(RMF)
491 tofederalinformationsystems.SystemstowhichtheRMFistobeappliedincludeNCCoE
492 usecaseandblockactivities.TheRMFpromotestheconceptofnearreal-timerisk
493 managementandongoinginformationsystemauthorizationthroughtheimplementation
494 ofrobustcontinuousmonitoringprocesses;providesseniorleaderswiththenecessary
495 informationtomakecost-effective,risk-baseddecisionswithregardtotheorganizational
496 informationsystemssupportingtheircoremissionsandbusinessfunctions;andintegrates
497 informationsecurityintotheenterprisearchitectureanddevelopmentlifecycle.Applying
498 theRMFwithinenterpriseslinksmanagementprocessesattheinformationsystemlevelto
499 managementprocessesattheorganizationlevelthroughariskexecutive(function)and
500 establisheslinesofresponsibilityandaccountabilityforsecuritycontrolsdeployedwithin
501 organizationalinformationsystemsandinheritedbythosesystems(i.e.,commoncontrols).
502 Thesix-stepRMFincludessecuritycategorization,securitycontrolselection,security
503 controlimplementation,securitycontrolassessment,informationsystemauthorization,
504 andsecuritycontrolmonitoring.WithrespecttotheCybersecurityFramework,SP800-37
505 assumesthatsystemcomponents,businessenvironmentandgovernancestructurehave
506 beenidentified.Theriskassessmentthatunderliescategorizationisbasedontheassumed
507 understandingofthesefactors.SP800-37alsofocusesonimpactsofsecurityincidents
508 ratherthanonthreatsthattakeadvantageofsystemvulnerabilitiestocreatethose
509 impacts.Thecontrolselection,controlimplementation,andsystemauthorization
510 recommendationsofSP800-37donotmapdirectlytotheCybersecurityFramework.

DNS-Based Email Security Practice Guide DRAFT 24


Chapter 4. Approach

511 However,SP800-37doesproviderecommendationsrelevanttoIdentify(ID.RA-5,ID.RA-6,
512 ID.RM1,andID.RM-2inSection3.1),Protect(PR.IP-3,andPR.IP-7inSections3.4and3.6),
513 andDetect,(DE.AE-5andDE.CM-1inSection3.6)elementsoftheCybersecurity
514 Framework.
515 3. Guidelines on Electronic Mail Security;NISTSpecialPublication;SP800-45Ver.2;Tracy,
516 Jansen,Scarfone,Butterfield;February2007.
517 http://csrc.nist.gov/publications/nistpubs/800-45-version2/SP800-45v2.pdf
518 SP800-45providesguidelinesintendedtoassistorganizationsininstalling,configuring,and
519 maintainingsecuremailserversandmailclients.Specifically,thepublicationdiscussesin
520 detail:
521 a. emailstandardsandtheirsecurityimplications
522 b. emailmessagesigningandencryptionstandards
523 c. theplanningandmanagementofmailservers
524 d. securingtheoperatingsystemunderlyingamailserver
525 e. mail-serverapplicationsecurity
526 f. email-contentfiltering
527 g. email-specificconsiderationsinthedeploymentandconfigurationofnetwork
528 protectionmechanisms,suchasfirewalls,routers,switches,andintrusiondetection
529 andintrusionpreventionsystems
530 h. securingmailclients
531 i. administeringthemailserverinasecuremanner,includingbackups,security
532 Assuggestedbyits2007publicationdate,SP800-45doesn'treflectthemostrecent
533 developmentsinelectronicmailsecurity,especiallythemorerecentIETFRFCs(e.g.,
534 SMIMEA12andTLSA13),buttherecommendationsitmakesarestillgermane.
535 WithrespecttotheCybersecurityFramework'sIdentifycategoryanditssubcategories,SP
536 800-45recommendsriskmanagementactivities,butdoesnotgointodetailthatmapsto
537 subcategoryreferences.IntheProtectcategory,subcategoryreferencesPR.AC-1,PR.AC-3,
538 PR.AC-4,PR.AC-5,PR.AT-1,PR.AT-2,PR.AT-5,PR.DS-2,PR.DS-6,PR.IP-2,PR.IP-4,andPR.PT-1
539 areaddressedbytheguideline.IntheDetectcategory,subcategoryreferencesDP-1and
540 DE.DP-4areaddressedbytheguideline.IntheRespondcategory,subcategoryreferences
541 DE.AE-2,DE.CM-1,DE.CM-4,DE.CM-5,DE.CM-8,DE.DP-1,andDE.DP-4areaddressed.In
542 theRespondcategory,subcategoryreferencesRS.RP-1,RS.CO-1,RS.CO-2,RS.AN-1,and
543 RS.IM-1areaddressedbytheguideline.IntheRecovercategory,subcategoryreference
544 RC.RP-1isaddressedbytheguideline.
545 4. Federal S/MIME V3 Client Profile,NISTSpecialPublication,SP800-49,Chernick,November
546 2002.http://csrc.nist.gov/publications/nistpubs/800-49/sp800-49.pdf

12. See Using Secure DNS to Associate Certificates with Domain Names For S/MIME
(draft-ietf-dane-smime-02)andUsing Secure DNS to Associate Certificates with Domain Names
For S/MIME(draft-ietf-dane-smime-12)
13.RFC6698,TheDNS-BasedAuthenticationofNamedEntities(DANE)TransportLayerSecurity
(TLS)Protocol:TLSA

DNS-Based Email Security Practice Guide DRAFT 25


Chapter 4. Approach

547 SP800-49wasdevelopedtoprovideorganizationswithapproachestoassurethat
548 Secure/MultipurposeInternetMailExtensions(S/MIME)productscaninteroperateand
549 meetthee-mailsecurityneedsoffederalagenciesbothwithrespecttosecurityfeatures
550 andadequatecryptographicalgorithms.Thisprofilestatesrequirementsfor
551 implementingsetsofcryptographicalgorithmsuitesspecifiedelsewherebythestandards
552 developmentorganizations.Theprofilespecifiesasetofe-mailsecurityfeatures(e.g.,
553 encryptede-mailandsignedreceipts)thataremandatoryforfederalagencies.SP800-49
554 addsspecificitytotheS/MIMEstandards,whileattemptingtoavoidviolatingthose
555 standards.Asits2002publicationdatesuggests,SP800-49isevenmoredatedwithrespect
556 toprotocolsthanSP800-45(e.g.,recommendingthenowdeprecatedSHA-1insteadof
557 SHA-2forhashing,andthedeprecatedTripleDESratherthanAESforencryption).However,
558 ittoo,makessecurityrecommendationsthatarestillgermane.TheSP800-49requirements
559 andrecommendationsfallintotheCybersecurityFrameworkProtectcategory.Itprovides
560 guidelinesthataddressthesubcategoryreferencesPR.DS-2,PR.DS-6,and(lessprecisely)
561 PR.PT-4.
562 5. Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS)
563 Implementations;NISTSpecialPublication;SP800-52Rev.1;Polk,McKay,Chokhani;April
564 2014.http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf
565 TransportLayerSecurity(TLS)providesmechanismstoprotectsensitivedataduring
566 electronicdisseminationacrosstheInternet.SP800-52providesguidanceintheselection
567 andconfigurationofTLSprotocolimplementations,whilemakingeffectiveuseofFederal
568 InformationProcessingStandards(FIPS)andNIST-recommendedcryptographicalgorithms.
569 SP800-52requiresthatTLS1.1beconfiguredwithFIPS-basedciphersuitesastheminimum
570 appropriatesecuretransportprotocolandrecommendedthatagenciesdevelopmigration
571 planstoTLS1.2byJanuary1,2015.ThisSpecialPublicationalsoidentifiesTLSextensions
572 forwhichmandatorysupportmustbeprovidedandsomeotherrecommendedextensions.
573 LikeSP800-49,theSP800-52requirementsandrecommendationsfallintothe
574 CybersecurityFrameworkProtectcategory.Theguidelineaddressesthesubcategory
575 referencesPR.DS-2,PR.DS-6,and(lessprecisely)PR.PT-4.
576 6. Security and Privacy Controls For Federal Information Systems And Organizations,NIST
577 SpecialPublication,SP800-53Rev.4,JointTaskForceTransformationInitiative,April2013.
578 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
579 SP800-53providesacatalogofsecurityandprivacycontrolsforfederalinformation
580 systemsandorganizationsandaprocessforselectingcontrolstoprotectorganizational
581 operations(includingmission,functions,image,andreputation),organizationalassets,
582 individuals,otherorganizations,andthenationfromadiversesetofthreats,including
583 hostilecyberattacks,naturaldisasters,structuralfailures,andhumanerrors.Thecontrols
584 arecustomizableandimplementedaspartofanorganization-wideprocessthatmanages
585 informationsecurityandprivacyrisk.Thecontrolsaddressadiversesetofsecurityand
586 privacyrequirementsacrossthefederalgovernmentandcriticalinfrastructurethatare
587 derivedfromlegislation,ExecutiveOrders,policies,directives,regulations,standards,
588 and/ormission/businessneeds.Thepublicationalsodescribeshowtodevelopspecialized
589 setsofcontrols,oroverlays,thataretailoredforspecifictypesofmissions/business
590 functions,technologies,orenvironmentsofoperation.Finally,thecatalogofsecurity
591 controlsaddressessecurityfrombothafunctionalityperspective(thestrengthofsecurity
592 functionsandmechanismsprovided)andanassuranceperspective(themeasuresof
593 confidenceintheimplementedsecuritycapability).Addressingbothsecurityfunctionality

DNS-Based Email Security Practice Guide DRAFT 26


Chapter 4. Approach

594 andsecurityassuranceensuresthatinformationtechnologyproductsandtheinformation
595 systemsbuiltfromthoseproductsusingsoundsystemsandsecurityengineeringprinciples
596 aresufficientlytrustworthy.
597 SP800-53Rev.4addressesallCybersecurityFrameworkcategoriesandsubcategories.Only
598 theRC.CO-1(Reputationafteraneventisrepaired)andRC.CO-2(Recoveryactivitiesare
599 communicatedtointernalstakeholdersandexecutiveandmanagementteams)references
600 undertheRecover:CommunicationssubcategoryarenotaddressedbySP800-53.
601 7. Recommendation for Key Management: Part 1 - General,NISTSpecialPublication800-57
602 PartRev.4,Barker,January2016;Part 2 - Best Practices for Key Management Organization,
603 NISTSpecialPublication800-57Part2,Barker,Barker,Burr,Polk,andSmid,August2005;
604 andPart 3 - Application-Specific Key Management Guidance,NISTSpecialPublication,SP
605 800-57Part3Rev.1,BarkerandDang,January2015.
606 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf,
607 http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf,
608 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf
609 NISTSpecialPublication800-57providescryptographickeymanagementguidance.Part1
610 providesgeneralguidanceandbestpracticesforthemanagementofcryptographickeying
611 material.Part2providesguidanceonpolicyandsecurityplanningrequirementsforU.S.
612 governmentagencies.Part3ofthisSpecialPublicationprovidesguidancewhenusingthe
613 cryptographicfeaturesofcurrentsystemsthatmaynotexhibitalloftheproperties
614 recommendedbyPart1oftheguideline.Part3includesapplications-specific
615 recommendationsfor,amongotherapplications,thePublicKeyInfrastructure(PKI),
616 InternetProtocolSecurity(IPsec),TransportLayerSecurity(TLS)Secure/MultipartInternet
617 MailExtensions(S/MIME),andDomainNameSystemSecurityExtensions(DNSSEC).Allof
618 theserecommendationsapplydirectlytotheDNS-BasedE-MailSecurityBuildingBlock.
619 SP800-57addressesalloftheCybersecurityFrameworkcategoriesexceptDetect.Auditis
620 theprimarymechanismreliedoninSP800-53fordetectionpurposes.Thecategoriesand
621 subcategoryreferencesthatareaddressedbytheguidelineincludeIdentify(ID.AM-2,
622 ID.BE-3,ID.BE-4,ID.BE-5,ID.GV-1,ID.GV-4,ID.RA-4,andID.RA-5),Protect(PR.AC-1,PR.AC-2,
623 PR.AC-3,PR.AC-4,PR.AT-2,PR.AT-3,PR.AT-4,PR.DS-1,PR.DS-2,PR.DS-3,PR.DS-4,PR.DS-6,
624 PR.IP-2,PR.IP-3,PR.IP-4,PR.IP-5,PR.IP-6,PR.IP-9,PR.PT-1,PR.PT-2,PR.PT-3,andPR.PT-4);
625 Respond(RS.RP-1,RS.CO-1,RS.CO-2,RS.CO-3,RS.AN-2,andRS.MI-2);andRecover
626 (RC.RP-1).
627 8. Secure Domain Name System (DNS) Deployment Guide,NISTSpecialPublication,SP
628 800-81-2,ChandramouliandRose,September2013.
629 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf
630 TheDNSisadistributeddatabasethatenablesaccesstoInternetresourcesviauser-friendly
631 domainnames,ratherthanIPaddresses,bytranslatingdomainnamestoIPaddressesand
632 back.TheDNSinfrastructureismadeupofcomputingandcommunicationentitiescalled
633 nameservers,eachofwhichcontainsinformationaboutasmallportionofthedomain
634 namespace.ThenamedataprovidedbyDNSisintendedtobeavailabletoanycomputer
635 locatedanywhereintheInternet.SP800-81-2providesdeploymentguidelinesforsecuring
636 DNSwithinanenterprise.TheprimarysecuritygoalsforDNSaredataintegrityandsource
637 authentication,whichareneededtoensuretheauthenticityofnameinformationand
638 maintaintheintegrityofnameinformationintransit.Thisdocumentprovidesextensive
639 guidanceonmaintainingdataintegrityandperformingsourceauthentication.This

DNS-Based Email Security Practice Guide DRAFT 27


Chapter 4. Approach

640 documentpresentsguidelinesforconfiguringDNSdeploymentstopreventmany
641 redirectionattacksthatexploitvulnerabilitiesinvariousDNScomponents.
642 ThecategoriesandsubcategoryreferencesthatareaddressedarelimitedtoIdentify
643 (ID.AM-2andID.RA-6),Protect(PR.AC-1,PR.AC-3,PR.AC-5,PR.AT-2,PR.DS-2,PR.DS-5,
644 PR.DS-6,PR.IP-3,PR.IP-4,PR.IP-6,andPR.IP-9),andDetect(DE.CM-1andDE.CM-7).
645 9. A Framework for Designing Cryptographic Key Management Systems;NISTSpecial
646 Publication;SP800-130;Barker,Branstad,Smid,Chokhani;August2013.
647 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-130.pdf
648 SP800-130'sframeworkforDesigningCryptographicKeyManagementSystems(CKMS)
649 containstopicsthatshouldbeconsideredbyaCKMSdesignerwhendevelopingaCKMS
650 designspecification.Foreachtopic,thereareoneormoredocumentationrequirements
651 thatneedtobeaddressedbythedesignspecification.Thus,anyCKMSthataddresseseach
652 oftheserequirementswouldhaveadesignspecificationthatiscompliantwiththis
653 framework.ACKMSwillbeapartofalargerinformationsystemthatexecutesprocessing
654 applications.WhiletheCKMSsupportstheseapplicationsbyprovidingcryptographickey
655 managementservices,theparticularapplicationsorparticularclassesofapplicationsare
656 beyondthescopeofthisframework.
657 SP800-130addressesalloftheCybersecurityFrameworkcategoriesThecategoriesand
658 subcategoryreferencesthatareaddressedincludeIdentify(ID.BE-4,ID.GV-1,ID.GV-2,
659 ID.GV-3,ID.GV-4,ID.RA-1,ID.RA-2,ID.RA-3,ID.RA-5,andRM-1);Protect(PR.AC-1,PR.AC-2,
660 PR.AC-4,PR.AC-5,PR.AT-1,PR.AT-2,PR.AT-4,PR.AT-5,PR.DS-1,PR.DS-2,PR.DS-3,PR.DS-6,
661 PR.DS-7,PR.IP-1,PR.IP-3,PR.IP-4,PR.IP-5,PR.IP-6,PR.IP-9,PR.MA-1,PR.PT-1,PR.PT-2,
662 PR.PT-3,andPR.PT-4);Detect(DE.AE-4,DE.CM-1,DE.CM-4,DE.CM-7,DE.CM-8,DE.DP-1,
663 DE.DP-2,DE.DP-3,andDE.DP-5);Respond(RS.RP-1,RS.CO-1,RS.CO-2,RS.AN-2,RS.MI-1,
664 andRS.MI-2);andRecover(RC.RP-1).
665 10. A Profile for U.S. Federal Cryptographic Key Management Systems (CKMS);ThirdDraft;NIST
666 SpecialPublication;SP800-152;Barker,Smid,Branstad;December18,2014.
667 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-152.pdf
668 DraftSP800-152coversmajoraspectsofmanagingthecryptographickeysthatprotect
669 federalinformation.Associatedwitheachkeyisspecificinformation(e.g.,theowner
670 identifier,itslength,andacceptableuses)calledmetadata.Thecomputers,software,
671 modules,communications,androlesassumedbyoneormoreauthorizedindividualswhen
672 managingandusingcryptographickeymanagementservicesarecollectivelycalleda
673 CryptographicKeyManagementSystem(CKMS).TheProfileforU.S.FederalCryptographic
674 KeyManagementSystems(FCKMSs)hasbeenpreparedtoassistCKMSdesignersand
675 implementersinselectingthefeaturestobeprovidedintheirproducts,andtoassist
676 federalorganizationsandtheircontractorswhenprocuring,installing,configuring,
677 operating,andusingFCKMSs.
678 SP800-130addressesalloftheCybersecurityFrameworkcategories.Thecategoriesand
679 subcategoryreferencesthatareaddressedincludeIdentify(ID.AM-3,ID.AM-5,ID.BE-4,
680 ID.BE-5,ID.GV-1,ID.GV-2,ID.GV-3,ID.GV-4,ID.RA-1,ID.RA-3,ID.RA-5,ID.RA-6,RM-1,and
681 RM-2);Protect(PR.AC-1,PR.AC-2,PR.AC-3,PR.AC-4,PR.AC-5,PR.AT-1,PR.AT-2,PR.AT-4,
682 PR.AT-5,PR.DS-1,PR.DS-2,PR.DS-3,PR.DS-4,PR.DS-6,PR.DS-7,PR.IP-1,PR.IP-3,PR.IP-4,
683 PR.IP-5,PR.IP-6,PR.IP-7,PR.IP-8,PR.IP-9,PR.IP-12,PR.MA-1,PR.PT-1,PR.PT-2,PR.PT-3,and
684 PR.PT-4);Detect(DE.AE-4,DE.CM-1,DE.CM-4,DE.CM-7,DE.CM-8,DE.DP-1,DE.DP-2,

DNS-Based Email Security Practice Guide DRAFT 28


Chapter 4. Approach

685 DE.DP-3,andDE.DP-5);Respond(RS.RP-1,RS.CO-1,RS.CO-2,RS.AN-2,RS.MI-1,RS.MI-2,
686 RS.MI-3,andRS.IM-2);andRecover(RC.RP-1andRC.IM-2).
687 11. Trustworthy Email;NISTSpecialPublication800-177;Chandramouli,Garfinkle,Nightingale
688 andRose;DraftPublication;September2016.
689 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177.pdf
690 NISTSpecialPublication800-177servesasacomplimentarydocumenttoSP800-45.SP
691 800-177addressesemailprotocolsecurityandprovidesdescriptions,guidelinesand
692 recommendationsfordeployingnewemailsecurityprotocolssuchasSMTPoverTLS,email
693 supportedbyDANE,andothernon-cryptographicauthentication(e.g.SenderPolicy
694 Framework,etc.).DiscussionsofSMTPoverTLSandS/MIMErelatedirectlytotheworkon
695 theDNS-BasedEmailSecurityProjectbuilds.
696 WithrespecttotheCybersecurityFramework'sIdentifycategoryanditssubcategories,SP
697 800-177recommendsriskmanagementactivities,butdoesnotgointodetailthatmapsto
698 subcategoryreferences.IntheProtectcategory,subcategoryreferencesPR.AC-1,PR.AC-3,
699 PR.AC-4,PR.AC-5,PR.AT-1,PR.AT-2,PR.AT-5,PR.DS-2,PR.DS-6,PR.IP-2,PR.IP-4,andPR.PT-1
700 areaddressedbytheguideline.IntheDetectcategory,subcategoryreferencesDP-1and
701 DE.DP-4 areaddressedbytheguideline.IntheRespondcategory,subcategoryreferences
702 DE.AE-2,DE.CM-1,DE.CM-4,DE.CM-5,DE.CM-8,DE.DP-1,andDE.DP-4areaddressed.In
703 theRespondcategory,subcategoryreferencesRS.RP-1,RS.CO-1,RS.CO-2,RS.AN-1,and
704 RS.IM-1areaddressedbytheguideline.IntheRecovercategory,subcategoryreference
705 RC.RP-1isaddressedbytheguideline.

706 4.4.6 Other Security References Applied in the Design and Development
707 of the DNS-Based Email Security Project
708 Thefollowingreferencesprovidedadditionalsecurityandprotocolstandardsandguidelines
709 thatwereappliedduringdesignanddevelopmentoftheDNS-BasedEmailSecurityProject.
710 1. Systems Security Engineering: An Integrated Approach to Building Trustworthy Resilient
711 Systems,Draft,NISTSpecialPublication,SP800-160,May2014.
712 http://csrc.nist.gov/publications/drafts/800-160/sp800_160_second-draft.pdf
713 NISTSpecialPublication160definessystemsecurityengineeringprocessesthataretightly
714 coupledtoandfullyintegratedintowell-established,internationalstandards-basedsystems
715 andsoftwareengineeringprocesses.Theprojectsupportsthefederalcybersecurity
716 strategyofBuildItRight,ContinuouslyMonitorandconsistsofafour-phasedevelopment
717 approachthatwillculminateinthepublicationofthefinalsystemssecurityengineering
718 guidelineattheendof2014.Thefourphasesinclude:
719 a. Phase 1:Developmentofthesystemsecurityengineeringtechnicalprocessesbasedon
720 thetechnicalsystemsandsoftwareengineeringprocessesdefinedinISO/IEC/IEEE
721 15288:2008
722 b. Phase 2:Developmentoftheremainingsupportingappendices(i.e.,Information
723 SecurityRiskManagement(includingtheintegrationoftheRiskManagement
724 Framework[RMF],securitycontrols,andothersecurity-andrisk-relatedconceptsinto
725 thesystemssecurityengineeringprocesses),UseCaseScenarios,Rolesand
726 Responsibilities,SystemResiliency,SecurityandTrustworthiness,Acquisition

DNS-Based Email Security Practice Guide DRAFT 29


Chapter 4. Approach

727 Considerations,andtheDepartmentofDefenseSystemsEngineeringProcess(Summer
728 2014)
729 c. Phase 3:Developmentofthesystemssecurityengineeringnontechnicalprocesses
730 basedonthenontechnicalsystemsandsoftwareengineeringprocesses(i.e.,
731 Agreement,OrganizationalProject-Enabling,andProject)definedinISO/IEC/IEEE
732 15288:2008(Fall2014)
733 d. Phase 4:Alignmentofthetechnicalandnontechnicalprocessesbasedontheupdated
734 systemsandsoftwareengineeringprocessesdefinedinISO/IEC/IEEEDIS15288:201x(E)
735 (FallorWinter2014,subjecttothefinalpublicationscheduleoftheinternational
736 standardsbodies)
737 Thefullintegrationofsecurityengineeringdisciplineintothesystemsandsoftware
738 engineeringdisciplineinvolvesfundamentalchangesinthetraditionalwaysofdoing
739 businesswithinorganizations.Thismayinvolvebreakingdowninstitutionalbarriersthat,
740 overtime,haveisolatedsecurityactivitiesfromthemainstreamorganizational
741 managementandtechnicalprocesses,including,forexample,thesystemdevelopmentlife
742 cycle,acquisition/procurement,andenterprisearchitecture.Theintegrationofthese
743 interdisciplinaryactivitiesrequiresthestrongsupportofseniorleadersandexecutives,and
744 increasedlevelsofcommunicationamongallstakeholderswhohaveaninterestin,orare
745 affectedby,thesystemsbeingdevelopedorenhanced.
746 2. Internet X.509 Public Key Infrastructure Certificate and CRL Profile;IETFRFC2459;Housley,
747 Ford,Polk,Solo;January1999.https://www.rfc-editor.org/rfc/rfc2459.txt
748 RFC2459isonepartofafamilyofstandardsfortheX.509PublicKeyInfrastructure(PKI)for
749 theInternet,buttheRFCisastandalonedocument;implementationsofthisstandard
750 proceedindependentfromtheotherparts.TheRFCprofilestheformatandsemanticsof
751 publickeycertificatesandcertificaterevocationlistsfortheInternet.Proceduresare
752 describedfortheprocessingofcertificationpathsintheInternetenvironment.Encoding
753 rulesareprovidedforpopularcryptographicalgorithms.Finally,ASN.1modulesare
754 providedintheappendicesforalldatastructuresdefinedorreferenced.
755 3. Threat Analysis of the Domain Name System (DNS),IETFRFC3833,AtkinsandAustein,
756 August2004.https://tools.ietf.org/html/rfc3833
757 RFC3833attemptstodocumentsomeoftheknownthreatstotheDNS,and,indoingso,
758 measuretheextenttowhichDNSSECisausefultoolindefendingagainstthesethreats.
759 4. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
760 Profile;ProposedStandard;IETFRFC5280;Cooper,Santesson,Farrell,Boeyen,Housley,
761 Polk;May2008.https://datatracker.ietf.org/doc/rfc5280/
762 RFC5280profilestheX.509v3certificateandX.509v2certificaterevocationlist(CRL)for
763 useintheInternet.TheRFCprovidesanoverviewandmodelofthespecifiedapproach,
764 describestheX.509v3certificateformatindetail,withadditionalinformationregardingthe
765 formatandsemanticsofInternetnameforms.Standardcertificateextensionsare
766 describedandtwoInternet-specificextensionsaredefined.Asetofrequiredcertificate
767 extensionsisalsospecified,theX.509v2CRLformatisdescribedalongwithstandardand
768 Internet-specificextensions,analgorithmforX.509certificationpathvalidationis
769 described,andanASN.1moduleandexamplesareprovided.
770 5. Simple Mail Transfer Protocol,IETFRFC5321,DraftStandard,Kleinstein,October2008.
771 https://tools.ietf.org/html/rfc5321

DNS-Based Email Security Practice Guide DRAFT 30


Chapter 4. Approach

772 RFC5321isaspecificationofthebasicprotocolforInternetelectronicmailtransport.It
773 coverstheSMTPextensionmechanismsandbestpracticesforthecontemporaryInternet,
774 butdoesnotprovidedetailsaboutparticularextensions.AlthoughSMTPwasdesignedasa
775 mailtransportanddeliveryprotocol,thisspecificationalsocontainsinformationthatis
776 importanttoitsuseasamailsubmissionprotocolforsplit-UA(UserAgent)mailreading
777 systemsandmobileenvironments.
778 6. Secure/Multipurpose Internet Mail Extensions (S/MIME),Version3.2,Message
779 Specification,ProposedStandard,IETFRFC5751,ISSN:2070-1721,RamsdellandTurner,
780 January2010.https://tools.ietf.org/html/rfc5751
781 RFC5751definesSecure/MultipurposeInternetMailExtensions(S/MIME)version3.2.
782 S/MIMEprovidesaconsistentwaytosendandreceivesecureMIMEdata.TheRFC
783 describesmethodsfordigitalsignaturestoprovideauthentication,messageintegrity,and
784 non-repudiationwithproofoforigin;encryptiontoprovidedataconfidentiality;andto
785 reducedatasize.
786 7. Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE),IETF
787 RFC6394,ISSN:2070-1721,Barnes,October2011.https://tools.ietf.org/html/rfc6394
788 Manycurrentapplicationsusethecertificate-basedauthenticationfeaturesinTransport
789 LayerSecurity(TLS)toallowclientstoverifythataconnectedserverproperlyrepresentsa
790 desireddomainname.Typically,thisauthenticationhasbeenbasedonPKIcertificatechains
791 rootedinwell-knowncertificateauthorities(CAs),butadditionalinformationcanbe
792 providedviatheDNSitself.ThisdocumentdescribesasetofusecasesinwhichtheDNSand
793 DNSSecurityExtensions(DNSSEC)couldbeusedtomakeassertionsthatsupporttheTLS
794 authenticationprocess.ThemainfocusofthisdocumentisTLSserverauthentication,butit
795 alsocoversTLSclientauthenticationforapplicationswhereTLSclientsareidentifiedby
796 domainnames.
797 8. The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security Protocol:
798 TLSA,ProposedStandard,IETFRFC6698,ISSN:2070-1721,HoffmanandSchlyter,August
799 2012.https://tools.ietf.org/html/rfc6698
800 EncryptedcommunicationontheInternetoftenusesTransportLayerSecurity(TLS),which
801 dependsonthirdpartiestocertifythekeysused.RFC6698providesmeanstoimproveon
802 thatsituationbystandardizingonmethodstoenabletheadministratorsofdomainnames
803 tospecifythekeysusedinthatdomain'sTLSservers.Thisrequiresmatchingimprovements
804 inTLSclientsoftware,butnochangeinTLSserversoftware.
805 9. Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate
806 Revocation List (CRL) Profile, Proposed Standard,IETFRFC6818,ISSN:2070-1721,Yee,
807 January2013.https://tools.ietf.org/html/rfc6818
808 RFC6818updatesRFC5280,theInternet X.509 Public Key Infrastructure Certificate and
809 Certificate Revocation List (CRL) Profile.Itchangesthesetofacceptableencodingmethods
810 fortheexplicitTextfieldoftheusernoticepolicyqualifierandclarifiestherulesfor
811 convertinginternationalizednamelabelstoASCII.TheRFCalsoprovidessomeclarifications
812 ontheuseofself-signedcertificates,trustanchors,andsomeupdatedsecurity
813 considerations.
814 10. SMTP security via opportunistic DANE TLS,RFC7672,DukhovniandHardaker,May26,2015.
815 https://tools.ietf.org/html/rfc7672

DNS-Based Email Security Practice Guide DRAFT 31


Chapter 4. Approach

816 TheRFCdescribesadowngrade-resistantprotocolforSMTPtransportsecuritybetween
817 MessageTransferAgents(MTAs),basedontheDNS-BasedAuthenticationofNamed
818 Entities(DANE)TLSADNSrecord.Adoptionofthisprotocolwillenableanincremental
819 transitionoftheInternetemailbackbonetooneusingencryptedandauthenticated
820 TransportLayerSecurity(TLS).
821 11. Using Secure DNS to Associate Certificates with Domain Names For S/MIME,IETFInternet
822 DraftWorkinProgress,draft-ietf-dane-smime-12,HoffmanandSchlyter,July31,2016.
823 https://datatracker.ietf.org/doc/draft-ietf-dane-smime/
824 ThedraftRFCforusingsecureDNStoassociatecertificateswithdomainnamesforS/MIME
825 describeshowtousesecureDNStoassociateanS/MIMEuser'scertificatewiththe
826 intendeddomainname;similartothewaythatDANE(RFC6698)doesforTLS.

827 4.5 Technologies


828 ThelaboratoryconfigurationemployedfortheDNS-BasedEmailSecurityprojectincluded
829 componentscontributedbyseveralsetsofcollaboratingorganizations.Oneofthecomponent
830 setsisWindows-based.TheothersareLinux-based.TherewerealsothreeMailUserAgents
831 (MUAs):MicrosoftOutlook,MozillaThunderbird(onLinux),andaThunderbirdMUAequipped
832 withaDANE-awareAppleKeyChainutility14thatwereabletointeracttoallthemailserversvia
833 IMAP.WhiletheWindows-basedcontributionusedServer2016DNSservices,theLinux-based
834 contributionsincludedthreedifferentimplementationsforDNS.OnewasbasedonNSD4and
835 Unboundauthoritativeandrecursiveservers,onewasbasedontheBerkeleyInternetName
836 Domain(BIND)DNSserver,andonewasbasedontheSecure64DNSservices.Secure64also
837 contributedDNSserviceshostedondedicatedprocessorsusingSecureTmicroO/Stechnology.
838 Collaboratorsassistedininstallationandinitialconfigurationofproductsand,asnecessary,in
839 compositionofcomponentsfordifferenttestcases.
840 Figure4.1belowdepicts,atahigh-level,collaboratorcontributionsusedtosupportthe
841 demonstrationproject.Elementsidentifiedinboldfacearecomponentsprovidedoradaptedby
842 thecollaborator.Otherelementswereincorporatedintothestacktopermitcheckingoutthe
843 installedcomponent'sfunctionality.
844 Collaboratorcontributionsidentifiedbelowareorganizedwithrespecttothecontributoras
845 initiallyinstalledandcheckedoutattheNCCoE.ThearchitecturedescribedinSection5below
846 permitsdemonstrationoftheinterconnectionofcomponentsprovidedbydifferent
847 collaboratorsandinitiallycheckedoutindependently.

14.AutilityforPublicKeyRetrievalintotheAppleKeyChain.ThisutilityisdeliveredonaMac-
BookloadedwithAppleMailandisaprogramfortheMacBookthatwillfetchSMIMEArecords
andputtheminthekeystoresothatwecandemonstrateend-to-endsecurity.

DNS-Based Email Security Practice Guide DRAFT 32


Chapter 4. Approach

848 Figure 4.1 DNS-Based Email Security Collaborator Contributions

849

850 4.5.1 Microsoft


851 TheMicrosoftenvironmentswerecontributedtosupportdemonstrationScenario1.Two
852 environmentswereconfiguredonthelaboratory'sVMwarevirtualmachines(Seefigure4.1
853 above).EachstackincludedtheabilitytodemonstrateOfficeOutlook15asanMUA,included
854 ExchangeServer201616asMTAs,andusedActiveDirectoryrunningonMicrosoftWindows
855 Server201617forDNSservices.TheMicrosoftcontributionincludedDNSSECawareDNS
856 recursiveserver,DNSSECawareDNSauthoritativeserver(IETFRFC4033,4034,and4035),an
857 MTAthatcandoSMTPoverTLS(RFC3207),managementtoolstoconfigureserversandfor
858 debuggingpurposes,X.509certificatesources,FIPS140-2validatedcryptographicsoftware,
859 andsupportformultifactorauthentication.Thestackswerealsoabletobeconfiguredto
860 demonstratethatExchangecouldbeusedwitheitheranOutlookoraThunderbirdMUA.Other
861 testcasesdemonstratedusingExchangewithacombinationofotherproviders'DNS
862 implementations.

15.https://en.wikipedia.org/wiki/Microsoft_Outlook
16.https://products.office.com/en/exchange/microsoft-exchange-server-2016
17.https://www.microsoft.com/en-us/server-cloud/products/windows-server-2016/

DNS-Based Email Security Practice Guide DRAFT 33


Chapter 4. Approach

863 4.5.2 NLnet


864 TheNLnetcontributionfocusedonDNSservicestosupportbothdemonstrationscenarios.
865 NLnetsoftwarewasinitiallyconfiguredonthelaboratory'sVMwarevirtualmachines.The
866 componentsincludedNSD44.1.918,Unbound19,andOpenDNSSEC20softwareforDNSservices
867 andPostfixandDovecotformailservices.NSD4isanauthoritativeonly,highperformance,
868 opensourcenameserver.Unboundisavalidating,recursive,cachingDNSresolver.
869 OpenDNSSECisasetofsoftwareforsigningDNSzonesthatarethenservedusingNSD.While
870 OpenDNSSECcanbeconfiguredtosignzonefilesortosignzonestransferredinviaDNSzone
871 transfer(AXFR),inthesescenarios,itisusedtosignlocalzonefilesinthesescenarios.Likewith
872 theMicrosoftstackabove,multipleMUAswereconfiguredtosendandreceivemailwiththe
873 NLnetcomponentsviaSMTPandIMAP.

874 4.5.3 ISC


875 TheISCcontributionwasfocusedontheBINDDNSserverandsupportedbothdemonstration
876 scenarios.BINDwasinitiallyconfiguredonthelaboratory'sVMwarevirtualmachinesand
877 includedconfigurationforPostfixandDovecotforemail.BIND21isopensourcesoftwarethatis
878 consideredthereferenceimplementationofDNS,butitisalsoproduction-gradesoftware,
879 suitableforuseinhigh-volumeandhigh-reliabilityapplications.BINDfeaturesresponserate
880 limiting(RRL),supportforFIPS140-2validatedhardwarecryptographicmodules,theoptional
881 abilitytoretrievezonedatadirectlyfromanexternaldatabase,theabilitytousein-linesigning
882 toautomaticallyre-signrecordsastheyareupdated,andascalablemaster/slavehierarchy.Like
883 theotherstacks,allthreeMUAswereabletoconnectandusethestackforDNSandemail.

884 4.5.4 Secure64


885 TheSecure64contributionswerefocusedonDNSservicestosupportbothdemonstration
886 scenarios.TheSecure64environmentincludedanautomatedonlineSecure64DNSSigneras
887 wellasDNSSEC-capableVMimagesofDNSCache,DNSAuthority,andDNSManager.DNS
888 ManagerprovidedcentralizedmanagementofSecure64DNSCachesoftwareand
889 configurationsandprovidednetwork-widemonitoringofkeyperformanceindicators.DNS
890 Managerallowedcreationofgroupsofserversandassignmentofconfigurationstoagroup,a
891 singleserver,orallservers.DNSAuthorityisanauthoritativesignerandserverasasingle
892 platform.DNSCache,DNSAuthority,andDNSManagerwereconfiguredonthelaboratory's
893 VMwarevirtualmachine;andtheDNSSignerwasprovidedasahigh-assuranceimplementation
894 deliveredonaSecure64dedicatedappliance.Secure64contributionswereabletodemonstrate
895 Outlook,Thunderbird,orThunderbirdequippedwithanAppleKeyChainutilityasMUAsand
896 usePostfixasanMTAandDovecottoprovideIMAPforclients.

18.http://www.nlnetlabs.nl/projects/nsd/
19.http://unbound.net
20.https://www.opendnssec.org
21.https://www.isc.org/downloads/bind/

DNS-Based Email Security Practice Guide DRAFT 34


1 5 Architecture
2 5.1 Usage Scenarios Supported .............................................................................................. 36
3 5.2 Architectural Overview ....................................................................................................... 38
4

DNS-Based Email Security Practice Guide DRAFT 35


Chapter 5. Architecture

5 TheSecurityplatformarchitectureusedfortheDNS-BasedEmailSecurityprojectincluded
6 combinationsofcomponentsfromdifferentsourcesthatsupportedtwousagescenariosfor
7 DANE-enabledsecureemailinfourdifferentsystemsenvironments.

8 5.1 Usage Scenarios Supported


9 Thescenariossupportedinclude:
10 ordinaryemailwheretheemailexchangesbetweentwoorganizations'emailservers
11 communicateoverTLSwithaSTARTTLSextension,andrelevantTLSArecordsarepublished
12 inthereceiver'sDNSzoneprotectedbyDNSSEC;and
13 end-to-endsignedemail,wheretheemailexchangesbetweenusersindifferent
14 organizationsarecarriedoverachannelprotectedbyTLS(usingtheSTARTTLSextension),
15 andrelevantartifactsusedforsigningandchannelprotectionarepublishedinaDNSzone
16 protectedbyDNSSEC.Subsequently,theseartifactsareusedforS/MIMEandTLSvalidation.
17 Inbothscenarios,end-entityandpersonalcertificatesweregeneratedfromCertificate
18 Authorities(CAs).Useofwellknown(i.e.installedastrustanchorsinhosts),localenterprise
19 CAs,andself-signedcertificatesweredemonstrated.
20 Whilethesecondscenariodemonstratedsigningofemails,itdoesnotincludeanend-to-end
21 encryptedemailscenario.Signingaddressesthemainsecurityconcernsinenterprise
22 environments,whicharethetargetoftheproject,butmayneglectconcernsofindividualusers
23 whomayalsowanttoreduceinformationdisclosuretotheiremailproviders.Thetwo
24 scenariosthatareincludedmay,however,serveasenablersforend-to-endencryption.
25 Participationbypartieshavingaprimarilyend-to-endencryptionfocusmaysucceedin
26 generatingindustrysupportforthebuildingblocksneededtosupportend-to-endencryption.
27 Inmoredetail,theproject'ssecurityplatformsusetheSTARTTLSextensiontoinclude
28 encryptionofcommunicationsbetweentwoMTAs,aswellasthesignatureofindividual
29 messagesusingS/MIME.TheencryptionanddecryptionwithS/MIMEontheenduser'sclient
30 wasexcludedfromthecurrentplatformdemonstration.

31 5.1.1 Usage Scenario 1


32 Anindividualneedstoenterintoanemailexchangewithanindividualinanotherorganization
33 Eachindividualexchangesemailviatherespectiveparentorganizations'mailservers.Users
34 connecttotheirorganizations'respectivemailserverswithinaphysicallyprotectedzoneof
35 control.
36 Inthisscenario,theprivacypolicyoftheparentorganizationsrequiresencryptionofthe
37 informationbeingexchanged.Thesecurityaffordedbythecryptographicprocessisdependent
38 ontheconfidentialityofencryptionkeysfromunauthorizedparties.Themailserversare
39 configuredtouseX.509certificatestoauthenticatethemselvesduringanencryptionkey
40 establishmentprocess.

DNS-Based Email Security Practice Guide DRAFT 36


Chapter 5. Architecture

41 DNSSECisemployedtoensurethateachsendingmailserverconnectstothelegitimateand
42 authorizedreceivingmailserverfromwhichitsX.509certificateisobtained.DANEresource
43 recordsareemployedtobindthecryptographickeyingmaterialtotheappropriateserver
44 name.STARTTLSisemployedtonegotiatethecryptographicalgorithmtobeemployedwithTLS
45 intheemailexchangeinwhichthePIIistransferred.Encryptionoftheemailmessageis
46 accomplishedbytheoriginator'semailserver,anddecryptionoftheemailmessageis
47 accomplishedbytherecipient'semailserver.
48 Demonstrationsofthesecurityplatforminthisscenarioincludeanattemptbyafraudulent
49 mailservertoposeasthelegitimatereceiveroftheemailandaman-in-the-middleattackerto
50 attempttodisruptthesignalthatTLSisavailableforthedesireddestination.Inthelatter
51 attack,thegoalistoforceunencryptedtransmissionoftheemail.Bothattemptsshouldfaildue
52 touseofDNSSECandDANE.

53 5.1.2 Usage Scenario 2


54 Anindividualneedstoenterintoanemailexchangewithanindividualinanotherorganization.
55 Eachindividualexchangesemailviatherespectiveparentorganizations'mailservers.Users
56 connecttotheirorganizations'respectivemailserverswithinaphysicallyprotectedzoneof
57 control.
58 Thepolicyoftheparentorganizationsrequirescryptographicdigitalsignatureofthemessage
59 toprovideintegrityprotectionsourceauthenticationoftheemailmessage.S/MIMEisawidely
60 availableandusedprotocolfordigitallysigningelectronicmail.Eachorganizationhastherefore
61 generatedX.509certificatesfortheirusersthatincludethepublicportionoftheirsignature
62 keys.ThesecertificatesarethenpublishedintheDNSusingtheappropriateDANEDNS
63 ResourceRecord(RR)type.
64 DNSSECisusedtoprovideassurancethattheoriginatinguser'smailserverconnectstothe
65 intendedrecipient'smailserver.DANErecordsareemployedtobindthecryptographic
66 certificatestotheappropriateserver(forTLS)andindividualuser(forS/MIME),respectively.
67 TLSisemployedtoprovideconfidentiality.Digitalsignatureoftheemailmessageis
68 accomplishedbytheoriginator'semailclient.Validatingthesignature(hencetheintegrityof
69 theauthorizationprovidedintheemailmessage)isaccomplishedbytherecipient'semail
70 client.
71 Demonstrationsofthesecurityplatforminthisscenarioincludeanattemptbyafraudulent
72 actortoposeastheoriginatoroftheemailandaman-in-the-middleattackerattemptingto
73 disruptthevalidationtheS/MIMEsignature.BothattemptsfailduetouseofDNSSECandDANE
74 records.

DNS-Based Email Security Practice Guide DRAFT 37


Chapter 5. Architecture

75 5.2 Architectural Overview


76 ThelaboratoryarchitecturefortheDNSSEC-BasedEmailSecurityprojectwasdesignedto
77 permitinterconnectionofMicrosoftOutlookandThunderbirdMUAswithMicrosoftExchange
78 andPostfix/DovecotMTAs.ItdemonstratestheinterconnectionofeitherMTAwithanyofthe
79 DNSservicescontributedbycollaborators.TwoinstantiationsofeachMTAtypewere
80 establishedtodemonstrateemailexchangesbetweenMTAsofthesametypeordifferent
81 types.ThevariouscomponentcombinationsarethendemonstratedwiththreedifferentTLSA
82 RRparameters:aself-signedcertificate,useoflocalcertificateauthorities,anduseof
83 well-knowncertificateauthorities.
84 Figure5.1isadeploymentdiagramofthearchitectureusedfordemonstratingDNS-Based
85 EmailSecurity.

86 Figure 5.1 DNS-Based Email Security Deployment Diagram

87

88 Fortestdocumentationpurposes,thereceivingMTAisnameddifferentlydependingonthe
89 receiver'sDNSservicezoneandtheTLSAoptionbeingdemonstrated.ThesendingMTA's
90 implementationandDNSinfrastructurecanalsovaryforeachtest,butsharethesamebasic
91 processes.

DNS-Based Email Security Practice Guide DRAFT 38


92 Thedesignoftheenvironmentpermitsinterconnectionofcomponentsprovidedbydifferentcollaborators(seefigure5.2).

93 Figure 5.2 DNS-Based Email Security Test Set-up

94

95 Thedepictionshowsthattheprojectsecurityplatformtest/demonstrationactivitywasbasedonthreedifferentclients,twoMTAs,and
96 fourDNSserviceconfigurationsinthelabattheNCCoEexchangingmessageswithNLnetLabsandSecure64.Allmessagesweresigned
97 (amailclientfunction)andencrypted(servertoserver).Weworkedwithoneremotelocationatatime,drivenbywhicheverisready
98 first.Themessageexchanges,includingDNSactivitywillbeloggedateachend(labandremotecorrespondent).

DNS-Based Email Security Practice Guide


DRAFT 39
Chapter 5. Architecture

99 Thesolidconnectorsinthedepictionillustrateonecase.Thedottedlinesdepicttheothercases
100 we'llwanttodemonstrate.Aswitchconventionisusedtoreflectconfigurationoptions,butthe
101 projectteamactuallyconfigureseachcomponentforeachoption.
102 TheorangearrowsbetweenthemailclientsandthePostfixMTAreflectthefactthatclients
103 submittedemaildirectlytotheSMTPserverforrelay,whileusingDovecotonlytogetmail.(The
104 depictioninfigure5.2reflectsthatIMAPisn'tusedtosubmitmail,onlyretrieveit,sotheMUA
105 sentmaildirectlytothePostfixserver,butreceivedthereplythroughtheDovecotserver.)
106 Theprojectteamdemonstrated30differenteventsusingvariouscombinationsofMUA,MTA,
107 andDNSServercomponentsdividedamongfivetestsequences.Ineachsequence,signedand
108 encryptedmessagesweresentfromasendertoarecipient.BothExchangeandPostfix
109 encryptedmailbydefault.Mostoftheexchangesemployedeitherself-signedcertificatesor
110 localCAs(seeAppendixC).TheBINDconfigurationwassetuptoobtainandvalidate
111 certificatesfromtheNISTAdvancedNetworksTechnologyDivision's(ANTD's)DNSsource
112 (actingasarootCA).(Seesection7belowfortestsequencesets.)BothExchangeandPostfix
113 encryptedmailbydefault.Mostoftheexchangesemployedeitherself-signedcertificatesor
114 localCAs.
115 Inonetestsequence,fraudulentlyS/MIMEsignedemailwassentfromamalicioussenderto
116 recipientsusingOutlookandThunderbirdMUAsconfiguredtouseExchangeandPostfixas
117 MTAs.TheOutlook/ExchangeconfigurationusedActiveDirectoryasitsDNSserver.The
118 configurationsemployingPostfix/DovecotMTAsweredemonstratedwitheachoftheother
119 threecontributedDNSServices.Inoneevent,theThunderbirdMUAemployedanAppleKey
120 ChainUtilitytoolthatallowsahosttoobtainX.509certificatesviaofDANERRs.Alleventswere
121 conductedusingwell-knownCAandEnterpriseCA-issuedcertificatesfortheimpersonated
122 sender.ThefraudulentsiteattemptedtospoofavalidsendingdomainbelongingtoaSecure64
123 sitethatwasconfiguredwithDNSAuthority/Cache/SignerDNSservices,aPostfix/Dovecot
124 MTA,andThunderbirdequippedwiththeAppleKeyChainutility.AnOutlook/Exchange/Active
125 Directoryset-upactedasthefraudulentsite.Theemailexchangebetweenorganizationswas
126 carriedoverTLS,andtheemailmessagewasS/MIMEsignedonthefraudulentusers'client
127 device.Theset-upforthissequenceisdepictedinfigure5.3below.
128 Inanothersequence,anNCCoEsystemattemptedtosendaTLSprotectedemailfromExchange
129 andPostfixMTAs(inturn)toanexternalPostfixMTAusingDNSAuthority/Cache/Signerfor
130 DNSservices.TheNCCoEExchangeMTAusedActiveDirectoryDNSServices,andthe
131 Postfix/DovecotMTAusedBINDandNSD4/Unbound/OpenDNSSECDNSservices.AS/MIME
132 signedemailwassenttoanexternalPostfixMTA.Foureventswereconductedusing
133 Well-KnownCAissuedcertificates,foureventswereconductedusingEnterpriseCAissued
134 certificates(TLSA/SMIMEARRparameterofCU=2)forTLSandS/MIMEonthereceiverside,
135 andthreeeventswereconductedusingself-signedcertificates(TLSA/SMIMEARRparameterof
136 CU=3)forTLSandS/MIMEonthereceiverside.AnOutlook/Exchange/ActiveDirectorystack
137 actedasaman-in-the-middleandattemptedtointerceptthemessage.Figure5.4depictsthe
138 configurationforaman-in-the-middledemonstration.Notethatthesenderisbeing
139 misdirectedtoamaliciousemailserveronly.Thisistosimulatealowerlevelattackwhereemail
140 issent(viaroutehijackingorsimilarlowlevelattack)toaMan-in-the-Middle.Figure5.4
141 depictstheconfigurationsusedwiththeThunderbird/Postfix/Dovecot/Bindoptionselected.

DNS-Based Email Security Practice Guide DRAFT 40


142 Figure 5.3 Fraudulent DNS Address Spoofing Configurations

143

DNS-Based Email Security Practice Guide


DRAFT 41
144 Figure 5.4 Man-In-The-Middle Event Configurations

145

146 Thefollowingsubsectionsdescribethearchitecture'sMUA,MTA,andDNSservicecomponentsandCybersecurityFrameworkCore
147 categoriessupportedbythosecomponents.

DNS-Based Email Security Practice Guide


DRAFT 42
Chapter 5. Architecture

148 5.2.1 Client Systems and Mail User Agents (MUAs)


149 ClientsystemsenvironmentsareMicrosoftOffice,AppleMail,andopen-sourceLinux-based
150 Thunderbirdapplications.Theseincludebothcommercialproductsandopen-sourcesoftware.
151 MUAcapabilitiesassociatedwiththeclientsystemsareusedtoinvokeS/MIMEdigitalsignature
152 andsignatureverificationforemail,butuser-to-userencryptionisnotdemonstrated.
153 Collaboratorsassistedininstallation,integrationtailoringasnecessary,andtestingof
154 laboratoryconfigurations.
155
Table 5.1 Client Systems

Collaborator Cybersecurity
Application Source
Configuration Support Framework Category

OfficeOutlook Microsoft Microsoft PR.AC-1,PR.AC-2,


MailUserAgent PR.DS-1,PR.DS-2,
PR.DS-6,PR.PT-4,
RS.MI-2

Thunderbird Open(Mozilla) NLnetLabs PR.AC-1,PR.AC-2,


MailUserAgent PR.DS-1,PR.DS-2,
PR.DS-6,PR.PT-4,
RS.MI-2

Thunderbirdwith Secure64 Secure64 PR.AC-1,PR.AC-2,


AppleKeyChain PR.DS-1,PR.DS-2,
PR.DS-6,PR.PT-4,
RS.MI-2

156 5.2.2 Email Servers


157 EmailserversincludebothWindowsandLinux-based(Dovecot/Postfix)MailTransferAgents.
158 Server-to-serverencryptionwasdemonstratedinthePostfixenvironments.Authenticationof
159 domainandserveridentitywasbasedonDNSSEC-signedDANErecords.UseoftheseDANE
160 recordsisonlysupportedbyPostfixatthetimeofthisproject.TheMTAssupporteachofthe
161 CybersecurityFrameworkFunctions,Categories,andSubcategoriesidentifiedinsection4.4.4
162 above.TheserversweredemonstratedindifferentDNSenvironmentsanddifferentTLSARR
163 usagescenarios.InordertodemonstraterepresentativeTLSAparameters,thedemonstrations
164 usedself-signedcertificates,end-entitycertificatesgeneratedbywell-knownCAsand
165 end-entitiesgeneratedbyenterpriselocalCAs.

DNS-Based Email Security Practice Guide DRAFT 43


Chapter 5. Architecture

166
Table 5.2 Mail Transfer Agents

Collaborator Configuration Cybersecurity


Application Source
Support Framework Category

Exchange2016a Microsoft Microsoft PR.AC-1,PR.AC-2,


PR.AC-3,PR.AC-5,
MailTransferAgent
PR.DS-1,PR.DS-239,
TLScapable PR.DS-6,PR.PT-439,
DE.CM-1,DE.CM-2,
DE.DP-4,RS.RP-1,
RS.CO-2,RS.MI-2

Postfix Open NLnetLabs PR.AC-1,PR.AC-2,


MailTransferAgent (postfix.com) Fraunhofer PR.AC-3,PR.AC-5,
PR.DS-1,PR.DS-2,
TLScapable Secure64 PR.DS-6,PR.PT-4,
DANEcapable DE.CM-1,DE.CM-2,
DE.DP-4,RS.RP-1,
RS.CO-2,RS.MI-2

a. ExchangeprovidedintegrityprotectiononlyforPR.DS-1,PR.DS-2,andPR.PT-4(Scenario2).

167 5.2.3 DNS Servers


168 BothWindowsandLinux-basedDNSserverandsupportcomponentswerecontributed.DNS
169 servicesprovidedincludeDNSSECvalidatingDNSresolvers(stubandrecursive)and
170 authoritativeDNSserversforDNSSECsignedzones.SupportforSMIMEAandTLSArecordswas
171 demonstrated.TheDNSservercomponentssupporteachoftheCybersecurityFramework
172 Functions,Categories,andSubcategoriesidentifiedinsection4.4.4abovewiththeexceptionof
173 PR.DS-1(protectionofdata-at-rest).
174
Table 5.3 DNS Servers

Collaborator Cybersecurity
Application Source
Configuration Support Framework Category

ActiveDirectoryand Microsoft Microsoft PR.AC-1,PR.AC-2,


WindowsServer2016 PR.AC-3,PR.AC-5,
SupportsDNSSEC PR.DS-2,PR.DS-6,
PR.PT-4,DE.CM-1,
DE.CM-2,DE.DP-4,
RS.RP-1,RS.CO-2,
RS.MI-2

BINDa Open(ISC) InternetSystems PR.AC-1,PR.AC-2,


Consortium(ISC) PR.AC-3,PR.AC-5,
SupportsDNSSEC
PR.DS-2,PR.DS-6,
SupportsDANE PR.PT-4,DE.CM-1,
DE.CM-2,DE.DP-4,
RS.RP-1,RS.CO-2,
RS.MI-2

DNS-Based Email Security Practice Guide DRAFT 44


Chapter 5. Architecture

Table 5.3 DNS Servers

Collaborator Cybersecurity
Application Source
Configuration Support Framework Category

NSD4 Open(NLnetLabs) Open(NLnetLabs) PR.AC-1,PR.AC-2,


SupportsDNSSEC PR.AC-3,PR.AC-5,
PR.DS-2,PR.DS-6,
SupportsDANE PR.PT-4,DE.CM-1,
Unbound DE.CM-2,DE.DP-4,
SupportsDNSSEC RS.RP-1,RS.CO-2,
RS.MI-2
OpenDNSSEC

DNSAUTHORITY Secure64 Secure64 PR.AC-1,PR.AC-2,


DNSMANAGER PR.AC-3,PR.AC-5,
PR.DS-1,PR.DS-6,
SupportsDNSSEC PR.PT-4,DE.CM-1,
SupportsDANE DE.CM-2,DE.DP-4,
(Cachingauthorityis RS.RP-1,RS.CO-2,
labeledDNSCACHE, RS.MI-2
andsignerrunsona
dedicatedprocessor)

a. ThenameBINDstandsforBerkeleyInternetNameDomain.

175

DNS-Based Email Security Practice Guide DRAFT 45


1 6 Outcome
2 Thissectiondiscussesthesecurityplatformfromtheperspectiveoftheuserandthesystem
3 administrator.Wedefinesystemadministratorasapersonwithintheorganizationwhohas
4 elevatedprivilegesonthemanagementsystemsinthebuild.Systemadministrationfunctions
5 includeidentificationofsystemcomponents,systeminstallation,systemintegration,system
6 configuration,configurationmonitoring,identificationofexceptionconditions,system
7 maintenance,andstatusreportingtomanagement.

8 6.1 The Users Experience


9 Theuser'sexperiencevariesfromrelativelyminimaladditionalimpactinenterprise
10 environmentswithestablishedsystemadministrationandsupporttoasignificantimpactinthe
11 caseofindividualself-supportedusers.Wheretheenterpriseofferssystemsadministrationand
12 supportservices,theuser'sexperiencewithrespecttoDNSservicesisessentiallyunchanged.
13 Oneexceptionisthat,whereDNSSECauthenticationfails,emailmessagessenttoorbyauser
14 willnotbedelivered.Thisshouldbeanuncommonexperienceforcorrespondentsbutitisup
15 totheenterpriseDNSadministratortopreventthishappening.
16 Similarly,forserver-to-serverencryption,thesecurityprotectionfeaturesshouldbeessentially
17 transparenttotheuser.
18 Foruser-to-userdigitalsignature,theusermustfirsthaveacertificateinstalledintheirMUA.
19 Thismaybeincludedindigitalidentitycredentials,oritmaybeprovidedbythesystem
20 administratorintheprocessofprovisioningtheuser'scomputer.Otherwise,theprocedure
21 requiredwouldbesimilartothatfollowedinsection3.2ofSP1800-6C.Thestepsrequiredvary
22 fromplatformtoplatform(e.g.,Windows,Linux,Mac),useragenttouseragent(e.g.,Outlook
23 vsThunderbird)andhowtheprivatekeyisstored(onthesystem,smartcards,etc.).
24 Representativeuserrequirementsaredescribedbelow(inthiscaseforOutlookrunningon
25 MacBookandThunderbirdrunningonLinux.

26 6.1.1 Users Digital Signature Experience with Outlook on MacBook


27 Tousedigitalsignaturesandencryption,boththesenderandrecipientmusthaveamail
28 applicationthatsupportstheS/MIMEstandard(e.g.,Outlook).

29 Note: Before this procedure is started, a certificate must be added to the keychain on the
30 computer. For information about how to request a digital certificate from a certification authority,
31 see MacOS Help or click on Help on the Outlook tool bar.

32 1. OntheToolsmenu,clickAccounts.
33 2. Clicktheaccountthatistobeusedtosendadigitallysignedmessage,clickAdvanced,and
34 thenclicktheSecuritytab.

DNS-Based Email Security Practice Guide DRAFT 46


Chapter 6. Outcome

35 3. UnderDigital signing,ontheCertificatepop-upmenu,clickthecertificatethatistobe
36 used.

37 Note: The Certificate pop-up menu only displays certificates that are valid for digital signing or
38 encryption that have already been added to the keychain for the Mac OS X user account. To
39 learn more about how to add certificates to a keychain, see Mac OS Help.

40 4. Doanyofthefollowing:
41
To Do this

Makesurethatthedigitallysigned SelecttheSend digitally signed messages as clear


messagescanbeopenedbyall textcheckbox.
recipients,eveniftheydonothavean
S/MIMEmailapplicationandcan't
verifythecertificate

Allowtherecipientstosendencrypted Makesurethatsigningandencryptioncertificates
messagestoyou havebeenselectedonthisscreen,andthenselect
theInclude my certificates in signed messages
checkbox.

42 5. ClickOK,andthenclosetheAccountsdialogbox.
43 6. Inane-mailmessage,ontheOptionstab,clickSecurity,andthenclickDigitally Sign
44 Message.
45 7. Finishcomposingthemessage,andthenclickSend.

46 6.1.2 Users Digital Signature Experience with Thunderbird


47 Forpurposesofillustration,thedescriptionoftheuserexperiencewithThunderbirdalso
48 includedcertificatemanagementrequirements.TheexamplehereshowsbothS/MIMEand
49 PGPexamplesofcertificatemanagement.TheS/MIMEapproachisrecommended.Notethat
50 whenusingOpenPGP,aFIPS140-conformantversionshouldalwaysbeused.

51 6.1.2.1 S/MIME Certificate Management


52 S/MIMEcertificatesareusedfordigitallysignedandencryptede-mailmessages.For
53 informationaboutgettingorcreatingS/MIMEcertificates,see:
54 http://kb.mozillazine.org/Getting_an_SMIME_certificate.

55 Installing an S/MIME certificate

56 Note: Before a user can create or import his or her own certificate and private key, he or she
57 must first set a master password if this has not already been done. The master password is
58 needed so that imported certificates are stored securely. See
59 http://kb.mozillazine.org/Master_password for instructions for setting a master password.The
60 user may have his or her own personal certificate and private key in a .p12 or .pfx file, and may
61 wish to import it into Thunderbird. Once a Master Password has been set, the user can
62 import/install a personal S/MIME certificate from a .p12 or .pfx file by doing the following steps.

DNS-Based Email Security Practice Guide DRAFT 47


Chapter 6. Outcome

63 1. OpentheCertificateManagerbygoingtoTools -> Options... -> Advanced -> Certificates ->


64 Manage Certificates....
65 2. GotothetabnamedYour Certificates.
66 3. ClickonImport.
67 4. SelectthePCKS12certificatefile(.pfxor.p12).
68 5. Itwillasktheuserforthemasterpasswordforthesoftwaresecuritydevice.Theuserenters
69 hisorhermasterpasswordandclicksOK.
70 6. Next,itwillasktheuserforthepasswordprotectinghisorherpersonalcertificate.Ifthe
71 user's.p12or.pfxfilehasapassword,heorsheentersithere,otherwiseleavethisfield
72 empty.ThenclickOK.
73 TheS/MIMEcertificateshouldnowhavebeenimported.Ifthecertificatewasnottrusted,
74 consulttheinstructionsat
75 http://kb.mozillazine.org/Thunderbird_:_FAQs_:_Import_CA_Certificate.

76 Configuring Thunderbird for using the certificate to sign email


77 GotoTools -> Account Settings...inThunderbird.Thenfindtheaccountwiththeemailaddress
78 thatmatchestheemailaddressinthecertificatethathasjustbeeninstalled.ChooseSecurity
79 underthataccountandselectthecertificatethathasjustbeeninstalled.Therestoftheoptions
80 shouldbeselfexplanatory.WhentheuserselectsacertificateinAccountSettings,that
81 selectiononlyappliestotheaccount'sdefaultidentityoridentities.Thereisnouserinterface
82 forspecifyingcertificatesforanaccount'sotheridentities.Ifdesired,thiscanbeworkedaround
83 byeditingthesettingsmanually,copyingthesettingsfromanaccount'sdefaultidentityto
84 someotheridentity.Thesettingshavenamesendingin:signing_cert_name,sign_mail,
85 encryption_cert_nameandencryptionpolicy.

86 User Installation of a Self-Signed S/MIME Certificate


87 IftheSMIMEcertificateinauser's.p12or.pfxfileisaself-signedcertificatefortheuser'sown
88 identity,thenbeforethatfilecanbeinstalledintothetabnamedYour Certificates,theuser
89 mustfirstinstallthatcertificateasacertificateauthorityintheAuthoritiestab.ThePKCS12
90 certificatefilewillnotinstallintotheAuthoritiestab.Theuserwillneedacopyofaself-signed
91 certificatethatdoesnotcontaintheuser'sprivatekey.Thisisusuallyintheformofa.cerfile.
92 Onewaytoobtainthe.cerformofacertificatefromthe.p12fileistousetheFirefoxAdd-on
93 KeyManagertoextractthe.cercertificatefromthe.p12file.WiththatAdd-oninstalledin
94 Thunderbird,theusergoestoTools -> Key Manager Toolbox -> Key Manager -> Your Keys,
95 selecthisorherkey,selectsExportandchoosesX.509asfileformat.
96 1. GotoTools -> Options... -> Advanced -> Certificates -> Manage Certificates....
97 2. GototheAuthoritiestab.
98 3. ClickonImport.
99 4. Selectthe.cerfile.
100 5. Itwillasktheuserforwhatpurposesheorshewantstotrustthecertificate.SelectTrust
101 this CA to identify email users.

DNS-Based Email Security Practice Guide DRAFT 48


Chapter 6. Outcome

102 6. ClickOKtocompletetheimport.

103 Note: Thunderbird automatically adds other people's S/MIME certificates to the Other People's
104 tab of a user's Certificate Manager when he or she receives from them a digitally signed
105 message with a valid signature and with an S/MIME certificate issued by a recognized and
106 trusted Certificate Authority (CA). CA certificates that appear in Thunderbird's Authorities tab
107 are recognized, and may also be trusted. CA certificates that do not appear in that tab are
108 considered unrecognized. An S/MIME certificate that was issued by an unrecognized CA will
109 not be automatically added to the Other People's tab of the user's Certificate Manager. If the
110 user attempts to manually import an S/MIME certificate that was issued by an unrecognized CA,
111 nothing will happen--literally. Thunderbird will not even display an error dialog. It will just not
112 import the S/MIME certificate. This is generally not a problem when receiving an S/MIME
113 certificate that was issued by a trusted Certificate Authority (CA), but could be a problem for a
114 certificate that was issued by an unrecognized or untrusted CA, or for a certificate that is
115 self-signed (i.e. it has no CA other than itself). So, before a user can import an S/MIME
116 certificate that is issued by an unrecognized CA or is self-signed, he or she must first acquire
117 and import the certificate for the issuing CA. In the case of a self-signed certificate, a .cer file
118 needs to be acquired from the individual whose certificate the user wishes to add.

119 6.1.2.2 PGP Example of Sending and Receiving Public Keys

120 Sending a public key via email


121 Tosendsignedmessagestootherpeople,theusermustfirstsendthemthepublickey:
122 1. Composethemessage.
123 2. SelectOpenPGPfromtheThunderbirdmenubarandselectAttach My Public Key.

124

125 3. Sendtheemailasusual.

126 Receiving a public key via email


127 Toverifysignedmessagesfromotherpeople,thepublickeymustbereceivedandstored:
128 1. Openthemessagethatcontainsthepublickey.
129 2. Atthebottomofthewindow,doubleclickontheattachmentthatendsin.asc.(Thisfile
130 containsthepublickey.)

DNS-Based Email Security Practice Guide DRAFT 49


Chapter 6. Outcome

131 3. ThunderbirdautomaticallyrecognizesthatthisisaPGPkey.Adialogboxappears,
132 promptingtheImportorViewofthekey.ClickImporttoimportthekey.

133

134 4. Aconfirmationthatthekeyhasbeensuccessfullyimportedwillbeshown.ClickOKto
135 completetheprocess.

136 Revoking a key


137 Iftheprivatekeymayhavebeencompromised(thatis,someoneelsehashadaccesstothefile
138 thatcontainstheprivatekey),revokethecurrentsetofkeysassoonaspossibleandcreatea
139 newpair.Torevokethecurrentsetofkeys:
140 1. OntheThunderbirdmenu,clickOpenPGPandselectKey Management.

141

142 2. Adialogboxappearsasshownbelow.CheckDisplay All Keys by Defaulttoshowallthe


143 keys.
144 3. Right-clickonthekeytoberevokedandselectRevoke Key.
145 4. Adialogboxappearsaskingtheuserifheorshereallywantstorevokethekey.Theuser
146 clicksRevoke Keytoproceed.
147 5. Anotherdialogboxappearsaskingfortheentryofasecretpassphrase.Theuserentersthe
148 passphraseandclicksOKtorevokethekey.
149 6. Theusersendstherevocationcertificatetothepeoplewithwhomheorshecorresponds
150 sothattheyknowthatthecurrentkeyisnolongervalid.Thisensuresthatifsomeonetries
151 tousethecurrentkeytoimpersonatetheuser,therecipientswillknowthatthekeypairis
152 notvalid.

DNS-Based Email Security Practice Guide DRAFT 50


Chapter 6. Outcome

153 6.1.2.3 Sending a Digitally Signed Email


154 1. Composethemessageasusual.
155 2. Todigitallysignamessage,selectOpenPGPfromtheThunderbirdmenuandenablethe
156 Sign Messageoption.

157

158 3. Iftheemailaddressisassociatedwithacryptographiccertificate,themessagewillbe
159 signedwiththekeycontainedinthatcertificate.Iftheemailaddressisnotassociatedwith
160 acryptographiccertificate,acertificatemustbeselectedfromalist.
161 4. Sendthemessageasusual.

162 6.1.2.4 Reading a Digitally Signed Email


163 Whenasignedmessageisreceived,andIfThunderbirdrecognizesthesignature,agreenbar
164 (asshownbelow)appearsabovethemessage.Todeterminewhetherornottheincoming
165 messagehasbeensigned,lookattheinformationbarabovethemessagebody.1

166

167 Ifthemessagehasbeensigned,thegreenbaralsodisplaysthetext,Signedmessage.A
168 messagethathasnotbeensignedcouldbefromsomeonetryingtoimpersonatesomeoneelse.

169 6.2 The System Administrators Experience


170 Thesystemadministrator(s)willgenerallyberesponsibleforconfiguringtheMUAs,MTA,and
171 DNSservers.Specificinstallationandconfigurationinstructionsandexamplesareprovidedin
172 Sections2,Section3,AppendixF,AppendixG,andAppendixHoftheHow-ToGuides,SP
173 1800-6C.ConfigurationincludessettingupandpublishingcertificatesintheDNSasTLSAand
174 SMIMEARRs.CertificatemanagementusingWell-KnownCA-issuedcertificatesorEnterprise
175 CA-issuedcertificatesisrequiredforfederalgovernmentapplicationsandisstrongly
176 recommendedinotherapplications.WhileinstructionsforconfigurationforDNSSECare
177 providedforenvironmentsdescribedinSP1800-6C,thismoresecuresetofconfiguration
178 optionsarenotgenerallyinvokedbydefault.Therefore,moreeffortandexpertiseareneeded
179 onthepartoftheDNSadministrator.

1.Ifthemessageisalsoencryptedonauser-to-userbasis,Thunderbirdwillalsoaskfortheentry
ofasecretpassphrasetodecryptthemessage.

DNS-Based Email Security Practice Guide DRAFT 51


Chapter 6. Outcome

180 Configuringandactivationofmailservers(MTAs)forchannelencryptionbydefaultisdescribed
181 insection3.3ofSP1800-6C.Summaryinformationisprovidedhereandinlinksforillustration
182 purposesforMicrosoftOffice365ExchangeandPostfix.
183 Ingeneral,thebulkofthesystemadministrator'seffortisinacquiringandpublishingthe
184 necessarycertificates.Maintenanceofthesecurityfunctions,oncethey'vebeensetup,isa
185 relativelyroutinesystemadministrationactivity.

186 6.2.1 Microsoft Exchange


187 OnlyMicrosoftExchangeforOffice365encryptsusers'datawhileit'sonMicrosoftserversand
188 whileit'sbeingtransmittedbetweentheMTSs.ExchangeforOffice365doesprovidecontrols
189 forendusersandadministratorstofinetunewhatkindofencryptionisdesiredtoprotectfiles
190 andemailcommunications.

191 6.2.2 Postfix


192 PostfixTLSsupportisdescribedathttp://www.postfix.org/TLS_README.html.Postfixcanbe
193 configuredtoalwaysuseTLSwhenofferedbyreceivers.2

2.SettingPostfixtoencryptalltrafficwhentalkingtoothermailservers,Snapdragon Tech
Blog,August9,2013.http://blog.snapdragon.cc/2013/07/07/setting-postfix-to-encrypt-all-traf-
fic-when-talking-to-other-mailservers/

DNS-Based Email Security Practice Guide DRAFT 52


1 7 Evaluation
2 7.1 Assumptions and Limitations ............................................................................................. 54
3 7.2 Testing................................................................................................................................ 54
4 7.3 Scenarios and Findings...................................................................................................... 57
5

DNS-Based Email Security Practice Guide DRAFT 53


Chapter 7. Evaluation

6 7.1 Assumptions and Limitations


7 Thissecuritycharacteristicevaluationhasthefollowinglimitations:
8 Itisnotacomprehensivetestofallsecuritycomponents,norisitaredteamexercise.
9 Itcannotidentifyallweaknesses.
10 Itdoesnotincludethelabinfrastructure.Itisassumedthatitsdevicesarehardened.
11 Testingthesedeviceswouldrevealonlyweaknessesinimplementationthatwouldnotbe
12 relevanttothoseadoptingthisreferencearchitecture.

13 7.2 Testing
14 Theevaluationincludedanalysisofthesecurityplatformstoidentifyweaknessesandtodiscuss
15 mitigations.Thefocusofthisportionoftheevaluationwashands-ontestingofthelaboratory
16 buildandexaminationofproductmanualsanddocumentation.Ourobjectivewastoevaluate
17 thebuildingblockandnotspecificproducts.ThepresenceoffourprimaryOSsfordomains
18 tested(Linux,MacOS,SourceTMicroOS,andWindows)madecompleteproduct-independent
19 hands-ontestingunrealistic.
20 Table7.1describesthegoalsofeachsequenceoftestcases.Foreachsequence,the
21 CybersecurityFramework(CSF)SubcategoriesandassociatedSP800-53control(s),thetest
22 environment(s)involved,andevaluationobjectiveofthetestareidentified.Theresultsofthe
23 testsareprovidedNISTSP1800-6c.
24 InalltestsequencesthesendingMTAattemptedtoestablishaTLSprotectedchanneltodeliver
25 theemailmessagetothereceiver.Intheattackscenarios,amaliciousactorattemptstodisrupt
26 thistransfer.Inalltestsequences,thesendingMUAsignedthemessage,andthereceiving
27 MUA,checkedthesignature.ExchangewasusedonlyforScenario2.1Inalltestsequences,the
28 sendingMTAattemptedtoverifythecorrectnessofallDNSresponsesviaDNSSECvalidation.In
29 mostscenarios,alice@<somedomain>sentanemailtobob@<receivername>.Bothsenders
30 andreceivershadtheirown(separate)DNSinfrastructuresconsistingofbothauthoritativeand
31 recursiveservers.TheExchangeasSendertestswereconductedforcompletenessandfor
32 examplesofSMTPoverTLSw/oDANEsupport-whatitlookedlikeandhowwellitworked.

1.ExchangeMTAsdidnotattempttoencryptordecryptMTA-to-MTAmessageexchanges.

DNS-Based Email Security Practice Guide DRAFT 54


33
Table 7.1 Tests Performed

Test CSF SP 800-53


Configuration Evaluation Objective
Sequence Subcategories Controls

Sequence1 PR.AC-1 AC-2,AC-17, AnOutlookMUA,interfacingwithanExchangeMTA,was EmailmessagesbetweenPostfixMTAswere


PR.AC-2 AC-19, configuredtouseActiveDirectoryandBINDDNSservices encryptedandsuccessfullydecryptedviaTLS.
AC-20, inturn.Eachofthesixconfigurationsexchangedemail (Scenario1).Signaturewaslogged.All
PR.DS-1 with messageswereS/MIMEsigned.Outlook
IAFamily,
PR.DS-2 IR-4,SC-8, aSecure64MUA/MTA/DNSservicestackthatincluded attemptedtoverifyreceivedmessages
PR.DS-6 SC-28,SI-7 aPostfixMTAandaThunderbirdMUArunningona (Scenario2).Signatureverificationresults
MacOSsystem werenoted.DNSnameverificationresults
RS.MI-2 werenoted.
anNLnetLabsMUA/MTA/DNSservicestackthat
includedaPostfixMTAandaThunderbirdMUA
runningonLinux
TheeventsincludeeventsshowinguseofWell-Known
CAs(CU-1),EnterpriseCAs(CU=2),andSelf-Signed
Certificates(CU=3)forTLSandS/MIME-enabledmail
receiversandS/MIME.Figure5.2abovedepictsthe
set-upforlaboratorysupportfortheSecure64
destinationvariantofthistestsequence.a

Sequence2 PR.AC-1 AC-2,AC-17, OutlookandThunderbirdMUAs,configuredtousea EmailmessagesbetweenMTAswere


PR.AC-2 AC-19, PostfixMTAwithDovecotIMAPsupport,wereconfigured encryptedandsuccessfullydecrypted.
AC-20, inturntouseBINDandSecure64'sDNSAuthority,DNS (Scenario1).Signatureandencryptionwere
PR.DS-1 Cache,andDNSSignerimplementations.Eachofthesix logged.AllmessageswereS/MIMEsigned.
IAFamily,
PR.DS-2 IR-4,SC-8, configurationsexchangedemailwithaSecure64 Outlookattemptedtoverifyreceived
PR.DS-6 SC-28,SI-7 MUA/MTA/DNSservicestackthatincludedaThundebird messages(Scenario2).Signatureverification
MUA,Postfix/DovecotMTA,andDNSSigner/DNS resultswerenoted.DNSnameverification
RS.MI-2 Cache/DNSAuthorityservicesforprocessingreceived resultswerenoted.
messages;andanNLnetLabsMUA/MTA/DNSservice
stackthatincludedaThundebirdMUA,Postfix/Dovecot
MTA,andNSD4,Unbound,andOpenDNSSECDNS
services.ThetesteventsincludeusingWell-KnownCA
issued(TLSA/SMIMEACU=1),EnterpriseCAissued
(CU=2),andSelf-SignedCertificates(CU=3).Figure5.2
abovedepictstheset-upforlaboratorysupportforthis
testsequence.

DNS-Based Email Security Practice Guide


DRAFT 55
Table 7.1 Tests Performed

Test CSF SP 800-53


Configuration Evaluation Objective
Sequence Subcategories Controls

Sequence3 PR.AC-1 AC-2,AC-4, FraudulentlyS/MIME-signedemailwassentfroma Thefraudulentsiteattemptedtospoofavalid


PR.AC-2 AC-17, malicioussendertorecipientsusingOutlookand sendingdomainbelongingtoaSecure64site.
AC-19, ThunderbirdMUAsconfiguredtouseExchangeand AnOutlook/Exchange/ActiveDirectoryset-up
PR.AC-3 AC-20, PostfixasMTAs.TheOutlook/Exchangeconfiguration actedasthefraudulentsite.Theemail
PR.AC-5 IAFamily, usedActiveDirectoryasitsDNSserver.The exchangebetweenorganizationswascarried
PR.DS-2 IR-4,SC-7, configurationsemployingPostfix/DovecotMTAswere overTLS,andtheemailmessagewasS/MIME
SC-8 demonstratedwitheachoftheotherthreecontributed signedonthefraudulentusers'clientdevice.
RS.MI-1 DNSServices.Inoneevent,theThunderbirdMUA WhereWell-KnownCA-issuedcertificatesor
employedanAppleKeyChainUtilitytoolthatallowsa EnterpriseCA-issuedcertificateswereused,
hosttoobtainX.509certificatesviaofDANERRs.All andtheMTAwasDANEaware.TheMUA
eventswereconductedusingwell-knownCAand usingaSMIMEAutilitywasabletodetectthe
EnterpriseCA-issuedcertificatesfortheimpersonated fraudulentemailandmarktheemailasnot
sender.Theset-upforthissequenceisdepictedin validated.
Figure5.3above.
Sequence4 PR.AC-1 AC-2,AC-4, ThesenderusedanOutlookMUAsendingmailthrougha Theman-in-the-middle,an
PR.AC-2 AC-17, Postfix/DovecotMTAandusing(inturn):ActiveDirectory Outlook/Exchange/ActiveDirectorystack,
AC-19, andDNSServer,BINDDNSServer,andNLnetLabsDNS attemptedtointercepttheemailfromthe
PR.AC-3 AC-20, Services.Self-signedcertificateswereusedonthe NCCoELaboratoryConfigurationbyactingas
PR.AC-5 IAFamily, legitimatereceiverside(TLSARRparameterCU=3)for aMan-in-the-Middle.TheemailandDNS
PR.DS-2 IR-4,SC-7, TLS.Eachofthethreeconfigurationsattemptedto transactionswereloggedineachcase,and
SC-8,SI-7 initiateanemailexchangewithanexternalSecure64site. theresultsareprovidedinVolumeCAppendix
PR.DS-6 Theset-upforthissequenceisdepictedinFigure5.4 C.WheretheMTAwasDANE-aware,A
RS.MI-1 above. detectedspoofing.Themailconnectiontothe
RS.MI-2 MTAwasestablishedbutclosedthe
connectionbeforethemailwastransferred.
Otherwise,theMTAfailedtodetectthe
man-in-the-middleandsenttheemail.

DNS-Based Email Security Practice Guide


DRAFT 56
Table 7.1 Tests Performed

Test CSF SP 800-53


Configuration Evaluation Objective
Sequence Subcategories Controls

Sequence5 PR.AC-1 AC-4,IR-5, ADANE-enabledPostfixMTAsentmessagetraffictofour Alargenumberofemailmessagesare


PR.DS-6 SC-5,SC-20, MTAswithoneAuthoritativeServerservingallfour generatedinthePostfixserverdeviceusinga
SC-21, zones.AnNSD4AuthoritativeDNSserverandUnbound Pythonscript,andthePostfixMTAsendsthe
PR.CM-1 SC-23,SI-4, recursiveserverwereprovidedforthePostfixsending messagestoeachoffourrecipientMTAsin
PR.DP-4 SI-13 MTA,andaSecure64DNSAuthorityandSignerprovided differentzones.IntherecipientMTArunning
PR.CO-2 theDNSservicesfortherecipientzones.Wereviewed withoutTLSAandthatrunningwithavalid
thelogfiles.OneoftherecipientMTAsdidnotemploy matchingTLSAandcertificateusagefieldset
TLSA,oneemployedavalidTLSAwiththeCUsetto3, to3,allmessagesshouldbeaccepted.Inthe
oneemployedaTLSAwithacertificateusagefieldof1, recipientMTAwithaTLSARRusingcertificate
butwithanincomplete(i.e.bad)PKIcertificationpath usageof1,butwithanincompletePKIX
(PKIXfailure),andoneemployedmismatchedserver validationpath,andtherecipientMTAwitha
cert/TLSAwiththecertificateusagefieldsetto3(DANE mismatchedcertificate/TLSA(certusage3),
validationfailure). thesendershouldclosetheconnection
withoutsendingthemessage.Logwatch
runningonthesendingPostfixserverdevice
loggedtheinstancesoffailuretodeliverdue
tocertificateexpirationorbadcertificate
path.

a. TheconnectionsdepictedintheFigureareactuallyfortheSecure64variantofthefirstSequence2configuration.CapabilitiesforSequence1supportareshownasdottedlines.

34 7.3 Scenarios and Findings


35 Oneaspectofoursecurityevaluationinvolvedassessinghowwellthereferencedesignaddressestheobjectivesofthescenarioitwas
36 intendedtosupport.

DNS-Based Email Security Practice Guide


DRAFT 57
Chapter 7. Evaluation

37 7.3.1 Scenario 1
38 Scenario1involvedtheordinaryexchangeofemailbetweentwoorganizations'emailservers
39 carriedoverTLS,wheretheTLSkeymanagementwasprotectedbyDANEandDNSSEC.Private
40 certificatesweregeneratedbyeitherwell-knownCAs,enterpriselocalCAsorself-signed.User
41 connectionstotheirorganizations'respectivemailserverswereestablishedandmaintained
42 withinaphysicallyprotectedzone,andemailwasencryptedbetweenmailserversusingTLS.
43 Theconfidentialityofencryptionkeyswasmaintainedsuchthatnounauthorizedthirdparty
44 hadaccesstothekeys.ThemailserversusedX.509certificatestostoreandtransportpublic
45 keystoestablishtheTLSchannel.DNSSECensuredthateachsendingmailserverreceivestheIP
46 addresstothelegitimateandauthorizedreceivingmailserverand(ifapplicable)validateits
47 X.509certificate.DANEboundthecryptographickeyingmaterialtotheappropriateserver.TLS
48 wasusedtoprotecttheconfidentialityoftheemailexchange.Encryptionoftheemailmessage
49 wasaccomplishedbytheoriginator'semailserver,anddecryptionoftheemailmessagewas
50 accomplishedbytherecipient'semailserverusingstandardserverlibraries.
51 Thetestsincludedanattemptbyafraudulentmailservertoposeasthelegitimatemail
52 receiverforadomain.Thetestsalsoincludeaman-in-the-middleattacktoattempttodisrupt
53 theTLSconnectionwiththeobjectiveofachievinganunencryptedtransmissionoftheemail.
54 BothattemptsfailedduetouseofDNSSECandDANE.Inbothcases,anindicationwasmade
55 availabletothesendingemailserverwhentheDNSSECsignatureassociatedwiththedomain
56 dataisdeterminedtobeinvalid.

57 7.3.2 Scenario 2
58 Scenario2involvedend-to-endsignedemail,wheretheemailexchangesbetween
59 organizationswerecarriedoverTLSasin(1),theemailmessagesweresignedandverifiedwith
60 S/MIMEontheend-users'clientdevices,andtheS/MIMEkeymanagementwasprotectedby
61 DANEandDNSSEC.Privatecertificatesweregeneratedbywell-knownandenterpriselocalCAs.
62 Self-signedcertificateswerenotused.Individualsestablishedconnectionstotheirdomains'
63 respectivemailserverswithinaphysicallyprotectedzoneofcontrol.Cryptographicdigital
64 signatureswereappliedtomessagestoprovideauthenticationandintegrityprotectionforthe
65 email.S/MIMEwastheprotocolusedforthedigitalsigning.Thesecertificateswerethen
66 encodedintheDNSusingtheappropriateDANEDNSrecordtype.DNSSECensuredthateach
67 originatinguser'smailserverconnectstotheintendedrecipient'smailserver.DANEboundthe
68 cryptographickeyingmaterialtotheappropriateserverandindividualuserdigitalsignature
69 certificates.TLSwasemployedtoprotecttheconfidentialityoftheemail.Digitalsigningof
70 emailmessageswasaccomplishedbyoriginator'sMUA,andcheckingthevalidityofthe
71 signature(hencetheintegrityoftheauthorizationprovidedintheemailmessage)was
72 accomplishedbyrecipient'sMUA.
73 Thetestsinthisscenarioincludedanattemptbyafraudulentactortoposeasanoriginatorof
74 theemail.ThisattemptfailedduetouseofDNSSECandDANE.ThereceivingMUA,usingathird
75 partySMIMEAtool,wasabletofetchthesendersrealS/MIMEcertificatefromtheDNSand
76 confirmthatthefraudulentemailwassignedusingadifferentcertificate.

DNS-Based Email Security Practice Guide DRAFT 58


Chapter 7. Evaluation

77 7.3.3 Effects of DANE Errors


78 Inadditiontothescenariosdescribedabove,aDANE-enabledPostfixMTAsentmessagetraffic
79 tofourotherpostfixMTAs.AsingleBINDinstancewassetuptoservetheTLSAandARRsfor
80 thefourreceivers.OneofthereceivingMTAsdidnotemployDANE.Thesecondemployed
81 DANEwithavalidTLSAwiththecertificateusagefield2setto3.ThethirdemployedaTLSAwith
82 acertificateusagefieldof2,butwithanincomplete(i.e.bad)PKIcertificationpath(generating
83 aPKIXvalidationfailure).TheTLSAcontainedalocalenterprisetrustanchor,buttheserverdid
84 nothavethefullcertificatechain(missingintermediatecertificate).Thefinaloneemployed
85 DANEwithaTLSARRusingCertificateUsageof3,buttherewasamismatchbetweentheserver
86 certandTLSARR(generatingaDANEvalidationfailure).
87 Littleornothingappearedinthesender'slogsformessagessenttoeithertheMTAnot
88 employingTLSortheemployingavalidTLSA.ThegrowthratesforlogsfortheMTAthat
89 employedaTLSAwithacertificateusagefieldof1,butwithaPKIXfailureandtheonethat
90 employedmismatchedservercert/TLSA(i.e.DANEvalidationfailure)weremeasured.
91 WhenthesenderwasconfiguredtoneveruseTLS,themailwassentinplaintextregardlessof
92 theTLS/DANEconfigurationofthereceiver.WhenthesenderwasconfiguredtouseTLS
93 opportunistically,itusedTLSregardlessofthestatusofthecertificate,orTLSA.Infact,the
94 senderdidnotissueaquerytofindTLSARRsevenifpublished.Whenthesenderused
95 opportunisticDANE,itusedTLSwhenavailableregardlessoftheDANEvalidationsresults.If
96 validationfailed,themailwasstillsentandtheresultwasloggedasanUntrustedor
97 AnonymousTLSconnection,dependingonthepresenceofaTLSARR.
98 Ofthefouroptionsusedinthelab,dane-onlyisthemostrigorousinwhatasenderwould
99 acceptbeforesendingmail.WhenthereceiverdidnotoffertheSTARTTLSoption,orlackeda
100 TLSARR,mailwasnotsent.Likewise,ifaTLSARRwaspresent,buttherewasanerrorin
101 validation(eithertheTLSARRitselfhadanerror,orPKIXfailed),themailwasnotsent.
102 Therefore,useofthisoptionisnotrecommendedforgeneraluseasthiswillresultinthe
103 majorityofemailbeingdeferred.Itshouldonlybeusedinscenarioswheresendersand
104 receiversarecoordinatedandmaintainastableDANEdeployment.

2.RFC6698,The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security


(TLS) Protocol: TLSA,Section2.1.1.https://tools.ietf.org/html/rfc6698#section-2.1.1

DNS-Based Email Security Practice Guide DRAFT 59


1 8 Future Build Considerations
2 Bothpublicsectorandprivatesectorenterprisesareheavilydependentonweb-based
3 technologyotherthanemailfore-commerceandotherpublic-facingapplications.Fraudulent
4 websitesposeatleastasgreatasecurityandprivacyproblemasfraudulentemail.Further,as
5 emailbecomesamoredifficultmediumformaliciousentitiestouseasapenetrationvector,
6 otherweb-basedmediawillbemoreintensivelyexploited.Already,emergingcommunications
7 trendsappeartobereplacingemailexchangesamongindividualswithothersocialmedia(e.g.,
8 Baidu,Facebook,FacebookMessenger,Google+,Instagram,Linkedin,Pinterest,Snapchat,
9 Tieba,Tumblr,Twitter,Viber,WhatsApp,andYouTube).Therefore,anextensionofthecurrent
10 projectthatfocusesonuseofimprovedDNSSECapplicationssuchasDANEforwebapplications
11 otherthanmailmaybejustified.
12 Additionally,thetestscenariosdidnotincludetheExchangeforOffice365MTAtodemonstrate
13 Scenario1.Futurebuildsmightbeconsideredtodemonstratethiscapability.
14 Finally,utilitiesarecurrentlyunderdevelopmentthatwouldprovideimprovedsupportfor
15 SMIMEAandimprovedsystemnotificationoffailedDNSSECsignaturevalidationevents.Future
16 buildsmightbeconsideredtodemonstratethesecapabilitiesaswell.

DNS-Based Email Security Practice Guide DRAFT 60


1 Appendix A Acronyms
2 ASN AbstractSyntaxNotation
3 AXFR DNSFullZoneTransferQueryType
4 BIND BerkeleyInternetNameDaemon
5 BSD BerkeleySoftwareDistribution
6 CA CertificateAuthority
7 CKMS CryptographicKeyManagementSystem
8 CRL CertificateRevocationList
9 CU CertificateUsageType
10 DANE DNS-basedAuthenticationofNamedEntities
11 DNS DomainNameSystem
12 DNSSEC DNSSecurityExtensions
13 Email ElectronicMail
14 EMC ElectromagneticCompatibility
15 EMI ElectromagneticInterference
16 FCKMS FederalCryptographicKeyManagementSystem
17 FIPS FederalInformationProcessingStandard
18 HIPAA HealthInsurancePortabilityandAccountabilityAct
19 IEC InternationalElectrotechnicalCommission
20 IEEE InstituteofElectricalandElectronicsEngineers
21 IETF InternetEngineeringTaskForce
22 IP InternetProtocol
23 IRS InternalRevenueService
24 ISO InternetOrganizationforStandardization
25 ITL InformationTechnologyLaboratory
26 MIME MultipurposeInternetMailExtension
27 MTA MailTransferAgent
28 MUA MailUserAgent
29 MX MailExchange(ResourceRecord)
30 NCCoE NationalCybersecurityCenterofExcellence
31 NIST NationalInstituteofStandardsandTechnology
32 OS OperatingSystem
33 PKI PublicKeyInfrastructure

DNS-Based Email Security Practice Guide


DRAFT 61
Appendix A.

34 PKIX PublicKeyInfrastructureX.509
35 RFC RequestforComments
36 RMF RiskManagementFramework
37 RR ResourceRecord
38 S/MIME Secure/MultipurposeInternetMailExtensions
39 SMIMEA S/MIMECertificateAssociation(ResourceRecord)
40 SMTP SimpleMailTransferProtocol
41 SP SpecialPublication
42 SQL StructuredQueryLanguage
43 TLS TransportLayerSecurity
44 TLSA TLSCertificateAssociation(ResourceRecord)
45 UA UserAgent
46 VLAN VirtualLocalAreaNetwork
47 VM VirtualMachine

DNS-Based Email Security Practice Guide


DRAFT 62
1 AppendixB References
2 Securing the Federal Government's Domain Name System Infrastructure,ExecutiveOfficeofthe
3 President,OfficeofManagementandBudget,M-08-23,August22,2008.https://
4 www.whitehouse.gov/sites/default/files/omb/memoranda/fy2008/m08-23.pdf
5 Enhancing the Security of Federal Information and Information Systems,ExecutiveOfficeofthe
6 President,OfficeofManagementandBudget,M-14-03,November18,2013.http://
7 www.whitehouse.gov/sites/default/files/omb/memoranda/2014/m-14-03.pdf
8 Improving Critical Infrastructure Cybersecurity,ExecutiveOfficeofthePresident,Executive
9 Order13636,February12,2013.https://www.federalregister.gov/articles/2013/02/19/
10 2013-03915/improving-critical-infrastructure-cybersecurity
11 Federal Information Security Management Act,UnitedStatesCongress,PublicLaw107-347,
12 December17,2002.https://www.govtrack.us/congress/bills/107/hr2458
13 Gramm-Leach-Bililey Act,UnitedStatesCongress,PublicLaw104-191,August21,1996.https:/
14 /www.gpo.gov/fdsys/pkg/PLAW-106publ102/html/PLAW-106publ102.htm
15 Health Insurance Portability and Accountability Act,UnitedStatesCongress,PublicLaw106-
16 102,November12,1999.https://aspe.hhs.gov/report/health-insurance-portability-
17 and-accountability-act-1996
18 Managing Information as a Strategic Resource,OMBCircularA-130,ExecutiveOfficeofthe
19 President,OfficeofManagementandBudget,July28,2016.https://
20 www.federalregister.gov/documents/2016/07/28/2016-17872/revision-of-omb-circular-
21 no-a-130-managing-information-as-a-strategic-resource
22 Rules Governing Practice before the Internal Revenue Service,InternalRevenueService,Circular
23 Number230,RevisedJune2014.https://www.irs.gov/tax-professionals/circular-230-
24 tax-professionals
25 Security Requirements for Cryptographic Modules,FederalInformationProcessingStandard
26 (FIPS),FIPS140-2,May2001(includingchangenoticesasof12-03-2002).http://
27 csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
28 Guide for Conducting Risk Assessments,NISTSpecialPublication,SP800-30Revision1,Joint
29 TransformationInitiative,September2012.http://csrc.nist.gov/publications/nistpubs/
30 800-30-rev1/sp800_30_r1.pdf
31 Guide for Applying the Risk Management Framework to Federal Information Systems: A security
32 Lifecycle Approach,NISTSpecialPublication,SP800-37Rev.1,JointTaskForce
33 TransformationInitiative;February2010withupdatesasofJune5,2014.http://
34 nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf
35 Guidelines on Electronic Mail Security;NISTSpecialPublication;SP800-45Ver.2;Tracy,Jansen,
36 Scarfone,Butterfield;February2007.http://csrc.nist.gov/publications/nistpubs/800-
37 45-version2/SP800-45v2.pdf
38 Federal S/MIME V3 Client Profile,NISTSpecialPublication,SP800-49,Chernick,November
39 2002.http://csrc.nist.gov/publications/nistpubs/800-49/sp800-49.pdf

DNS-BasedEmailSecurityPracticeGuide
DRAFT 63
AppendixB.

40 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS)
41 Implementations;NISTSpecialPublication;SP800-52Rev.1;Polk,McKay,Chokhani;
42 April2014.http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf
43 Security and Privacy Controls For Federal Information Systems And Organizations,NISTSpecial
44 Publication,SP800-53Rev.4,JointTaskForceTransformationInitiative,April2013.
45 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
46 Recommendation for Key Management: Part 1 - General,NISTSpecialPublication800-57Part
47 Rev.4,Barker,January2016.http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
48 NIST.SP.800-57pt1r4.pdf
49 Recommendation for Key Management: Part 2 - Best Practices for Key Management
50 Organization,NISTSpecialPublication800-57Part2,Barker,Barker,Burr,Polk,and
51 Smid,August2005.http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-
52 Part2.pdf
53 Recommendation for Key Management: Part 3: Application-Specific Key Management
54 Guidance,NISTSpecialPublication,SP800-57Part3Rev.1,BarkerandDang,January
55 2015.http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf
56 Electronic Authentication Guideline;SP800-63-2;Burr,Dodson,Newton,Perlner,Polk,Gupta,
57 Nabbus;August2013.doi:10.6028/NIST.SP.800-63-2[DirectLink]
58 Secure Domain Name System (DNS) Deployment Guide,NISTSpecialPublication,SP800-81-2,
59 ChandramouliandRose,September2013.http://nvlpubs.nist.gov/nistpubs/
60 SpecialPublications/NIST.SP.800-81-2.pdf
61 A Framework for Designing Cryptographic Key Management Systems;NISTSpecialPublication;
62 SP800-130;Barker,Branstad,Smid,Chokhani;August2013.http://nvlpubs.nist.gov/
63 nistpubs/SpecialPublications/NIST.SP.800-130.pdf
64 A Profile for U.S. Federal Cryptographic Key Management Systems (CKMS);ThirdDraft;NIST
65 SpecialPublication;SP800-152;Barker,Smid,Branstad;December18,2014.http://
66 nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-152.pdf
67 Systems Security Engineering: An Integrated Approach to Building Trustworthy Resilient
68 Systems,Draft,NISTSpecialPublication,SP800-160,Ross,McEvilley,Oren,May2016.
69 http://csrc.nist.gov/publications/drafts/800-160/sp800_160_second-draft.pdf
70 Trustworthy Email;NISTSpecialPublication;DRAFTSP800-177;Chandramouli,Garfinkle,
71 NightingaleandRose;DraftPublication;March29,September2016.http://
72 nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177.pdf
73 "InternetofThings:StandardsandGuidancefromtheIETF",IETF Journal,Kernenand
74 Bormann,April2016.https://www.internetsociety.org/publications/ietf-journal-april-
75 2016/internet-things-standards-and-guidance-ietf
76 X.509 Certificate Policy for the U.S. Federal PKI Common Policy Framework,Version1.21.http://
77 www.idmanagement.gov/documents/common-policy-framework-certificate-policy
78 Internet Protocol,RFC791,DARPA,September1981.https://tools.ietf.org/html/rfc791
79 Domain Names - Concepts And Facilities,RFC1034,Mockapetris,November1987.https://
80 www.ietf.org/rfc/rfc1034.txt
81 Domain Name System Structure and Delegation,RFC1591,Postel,March1994.https://
82 tools.ietf.org/html/rfc1591

DNS-BasedEmailSecurityPracticeGuide
DRAFT 64
AppendixB.

83 Internet X.509 Public Key Infrastructure Certificate and CRL Profile;IETFRFC2459;Housley,


84 Ford,Polk,Solo;January1999.https://www.rfc-editor.org/rfc/rfc2459.txt
85 The Secure HyperText Transfer Protocol,RFC2660,RescorlaandSchiffman,August1999.https:/
86 /tools.ietf.org/html/rfc2660
87 Threat Analysis of the Domain Name System (DNS),IETFRFC3833,AtkinsandAustein,August
88 2004.https://tools.ietf.org/html/rfc3833
89 A Method for Storing IPsec Keying Material in DNS,RFC4025,Richardson,February2005.
90 https://tools.ietf.org/html/rfc4025
91 DNS Security Introduction and Requirements;RFC4033;Arends,Austein,Larson,Massey,and
92 Rose;March2005.https://www.ietf.org/rfc/rfc4033.txt
93 A Border Gateway Protocol 4 (BGP-4);RFC4271;Rekhter,Li,andHares;January2006.https://
94 tools.ietf.org/html/rfc4271
95 The Transport Layer Security (TLS) Protocol Version 1.2,RFC5246,DierksandRescorla,August,
96 2008.https://tools.ietf.org/html/rfc5246
97 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile;
98 ProposedStandard;IETFRFC5280;Cooper,Santesson,Farrell,Boeyen(Entrust),
99 Housley,Polk;May2008.https://datatracker.ietf.org/doc/rfc5280/
100 Simple Mail Transfer Protocol,IETFRFC5321,DraftStandard,Kleinstein,October2008.https://
101 tools.ietf.org/html/rfc5321
102 Secure/Multipurpose Internet Mail Extensions (S/MIME),Version3.2,MessageSpecification,
103 ProposedStandard,IETFRFC5751,ISSN:2070-1721,RamsdellandTurner,January
104 2010.https://tools.ietf.org/html/rfc5751
105 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE),IETFRFC
106 6394,ISSN:2070-1721,Barnes,October2011.https://tools.ietf.org/html/rfc6394
107 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security Protocol:
108 TLSA,ProposedStandard,IETFRFC6698,ISSN:2070-1721,HoffmanandSchlyter,
109 August2012.https://tools.ietf.org/html/rfc6698
110 DNS-Based Service Discovery,RFC6763,CheshireandKrotchmal,February2013.https://
111 tools.ietf.org/html/rfc6763
112 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
113 List (CRL) Profile,ProposedStandard,IETFRFC6818,ISSN:2070-1721,Yee,January
114 2013.https://tools.ietf.org/html/rfc6818
115 SMTP security via opportunistic DANE TLS,RFC7672,DukhovniandHardaker,May26,2015.
116 https://tools.ietf.org/html/rfc7672
117 Using Secure DNS to Associate Certificates with Domain Names For S/MIME,IETFInternetDraft,
118 draft-ietf-dane-smime-09,HoffmanandSchlyter,September3,2015.https://
119 tools.ietf.org/html/draft-ietf-dane-smime-09
120 Domain Name System-Based Security for Electronic Mail,Barker,NationalInstituteofStandards
121 andTechnology'sDakotaConsultingIDIQContractSB1341-12-CQ-0011,TaskOrder15-
122 421Task3Report#2,December17,2016.https://nccoe.nist.gov/sites/default/files/
123 library/NCCoE_DNS-Based_Secure_E-Mail_BB.pdf

DNS-BasedEmailSecurityPracticeGuide
DRAFT 65
AppendixB.

124 Task2:Report#1onStandardsReviewandSupportforNCCoEProjectActivities,Barker,
125 NationalInstituteofStandardsandTechnology'sDakotaConsultingIDIQContract
126 SB1341-12-CQ-0011,TaskOrder15-421Task2Report#1,November30,2015.
127 Task3:Report#1onStandardsReviewandSupportforNCCoEProjectActivities,Barker,
128 NationalInstituteofStandardsandTechnology'sDakotaConsultingIDIQContract
129 SB1341-12-CQ-0011,TaskOrder15-421Task3Report#1,November30,2015.

DNS-BasedEmailSecurityPracticeGuide
DRAFT 66
Appendix C.

1 Appendix C DNS-Based Email Security Project Mapping to the


Framework Core and Informative References
3 ThefollowingtablesmapinformativeNISTandconsensussecurityreferencestoFrameworkCoresubcategoriesthatareaddressedby
4 theDNS-BasedEmailSecurityplatformset.Thereferencesdonotincludeprotocolspecificationsthatareimplementedbytheindividual
5 productsthatcomprisethedemonstratedsecurityplatforms.Whilesomeofthereferencesprovidegeneralguidancethatinforms
6 implementationofreferencedFrameworkCorefunctions,theNISTSpecialPublicationreferencesprovidespecificrecommendations
7 thatshouldbeconsideredwhencomposingandconfiguringsecurityplatformsfromDNSandemailcomponents,implementDNSSEC
8 andmailsecurityplatforms,andoperatingemailsystemssecurely.
9
Table C.1 PROTECT (PR)

Category Subcategory Informative References

Access Control (PR.AC):Accesstoassets PR.AC-1:Identitiesand NIST SP 800-45 Ver. 23,6


andassociatedfacilitiesislimitedto credentialsaremanagedfor NIST SP 800-53 Rev. 4AC-2,IAFamily
authorizedusers,processes,ordevices, authorizeddevicesand
andtoauthorizedactivitiesand users NIST SP 800-57 Part 2 3.1.2.1.3,A.3.2,B.5
transactions. NIST SP 800-81-211.7.2
NIST SP 800-1302.1,5,6.4.2,6.4.23,6.5,6.6.1,6.6.2,6.7.1,8.2.4
NIST SP 800-1522.10,4.8,4.9.1,5,6.4,6.5,6.6.1,6.6.2,6.7.1,8.2.3,10.1
NIST SP 800-1774.5,4.6.5,4.7,5.1
CCS CSC16
COBIT 5DSS05.04,DSS06.03
ISA 62443-2-1:20094.3.3.5.1
ISA 62443-3-3:2013SR1.1,SR1.2,SR1.3,SR1.4,SR1.5,SR1.7,SR1.8,SR1.9
ISO/IEC 27001:2013A.9.2.1,A.9.2.2,A.9.2.4,A.9.3.1,A.9.4.2,A.9.4.3

DNS-Based Email Security Practice Guide


DRAFT 67
Appendix C.

Table C.1 PROTECT (PR)

Category Subcategory Informative References

PR.AC-3:Remoteaccessis FIPS 140-2Sec.4


managed NIST SP 800-45 Ver. 29.5
NIST SP 800-53 Rev. 4AC17,AC-19,AC-20
NIST SP 800-57 Part 1 Rev. 45.3.1,6.2.2
NIST SP 800-81-27.2,9.8,11.7.5
NIST SP 800-1526.7.1,8.2,8.3
NIST SP 800-1774.4.2.1
COBIT 5APO13.01,DSS01.04,DSS05.03
ISA 62443-2-1:20094.3.3.6.6
ISA 62443-3-3:2013 SR1.13,SR2.6
ISO/IEC 27001:2013A.6.2.2,A.13.1.1,A.13.2.1

PR.AC-5:Networkintegrity OMB M-08-23


isprotected,incorporating NIST SP 800-45 Ver. 2 Rev. 48.1.4,9.5
networksegregationwhere
appropriate NIST SP 800-53 Rev. 4AC-4,SC-7
NIST SP 800-81-27.2.8,7.9,10.4
NIST SP 800-1306.8.6
NIST SP 800-1526.8.6,8.3
NIST SP 800-1773,7
ISA 62443-2-1:20094.3.3.4
ISA 62443-3-3:2013 SR3.1,SR3.8
ISO/IEC 27001:2013A.13.1.1,A.13.1.3,A.13.2.1

DNS-Based Email Security Practice Guide


DRAFT 68
Appendix C.

Table C.1 PROTECT (PR)

Category Subcategory Informative References

Data Security (PR.DS):Informationand PR.DS-1:Data-at-restis FIPS 140-2Sec.4


records(data)aremanagedconsistent protected NIST SP 800-53 Rev. 4SC-28
withtheorganization'sriskstrategyto
protecttheconfidentiality,integrity,and NIST SP 800-57 Part 1 Rev. 44.2.5,5.1.1,5.2.1,5.3.4,5.3.5,5.3.6,6.2.2.3
availabilityofinformation. NIST SP 800-57 Part 22.2,2.4,3.2,4.3,5.3.3,5.3.4,A.1.2,A.2.1,A.3.2
NIST SP 800-130 1,2.1,2.2,2.9,6.1,6.2,6.5
NIST SP 800-1522.2,4.3,4.6,4.7,6.1.3,6.4.14,6.4.29
CCS CSC17
COBIT 5APO01.06,BAI02.01,BAI06.01,DSS06.06
ISA 62443-3-3:2013SR3.4,SR4.1
ISO/IEC 27001:2013A.8.2.3

PR.DS-2:Data-in-transitis FIPS 140-2Sec.4


protected NIST SP 800-45 Ver. 2All
NIST SP 800-492
NIST SP 800-52 Rev. 13,4,D1.4
NIST SP 800-53 Rev. 4SC-8
NIST SP 800-57 Part 1 Rev. 44.2.5,5.1.1,5.2.1,5.3.4,5.3.5,5.3.6,6.2.1.3
NIST SP 800-57 Part 22.2,5.3.3,A.2,A.3.1,A.3.2
NIST SP 800-81-2All
NIST SP 800-1301,2.1,2.2,2.9,6.1,6.2,6.4,6.7.2
NIST SP 800-1526.1.2,6.2.1
NIST SP 800-177All
CCS CSC17
COBIT 5APO01.06,DSS06.06
ISA 62443-3-3:2013SR3.1,SR3.8,SR4.1,SR4.2
ISO/IEC 27001:2013A.8.2.3,A.13.1.1,A.13.2.1,A.13.2.3,A.14.1.2,A.14.1.3

DNS-Based Email Security Practice Guide


DRAFT 69
Appendix C.

Table C.1 PROTECT (PR)

Category Subcategory Informative References

PR.DS-6:Integritychecking FIPS 140-2Sec.4


mechanismsareusedto NIST SP 800-45 Ver. 22.4.2,3,4.2.3,4.3,5.1,6.1,7.2.2,8.2,9.2
verifysoftware,firmware,
andinformationintegrity NIST SP 800-492.2.1,2.3.2,3.4
NIST SP 800-52 Rev. 13,4,D1.4
NIST SP 800-53 Rev. 4 SI-7
NIST SP 800-57 Part 1 Rev. 45.5,6.1,8.1.5.1,B.3.2,B.5
NIST SP 800-57 Part 21,3.1.2.1.2,4.1,4.2,4.3,A.2.2,A.3.2,C.2.2
NIST SP 800-81-2All
NIST SP 800-1302.2,4.3,6.2.1,63,6.4,6.5,6.6.1
NIST SP 800-1526.1.3,6.2.1,8.2.1,8.2.4,9.4
NIST SP 800-1772.2,4.1,4.4,4,5,4,7,5.2,5.3
ISA 62443-3-3:2013SR3.1,SR3.3,SR3.4,SR3.8
ISO/IEC 27001:2013A.12.2.1,A.12.5.1,A.14.1.2,A.14.1.3

Protective Technology (PR.PT): PR.PT-4:Communications OMBM-08-23


Technicalsecuritysolutionsare andcontrolnetworksare FIPS140-2Sec.4
managedtoensurethesecurityand protected
resilienceofsystemsandassets, NISTSP800-492.4.3,2.4.4
consistentwithrelatedpolicies, NISTSP800-52Rev.13,4
procedures,andagreements. NISTSP800-53Rev.4AC-4,AC-17,AC-18,CP-8,SC-7
NISTSP800-57Part1Rev.45.3.1,6.2.2
NISTSP800-1308.3
NISTSP800-1524.7,4.11.1,6.8.6,8.3
CCSCSC7
COBIT5DSS05.02,APO13.01
ISA62443-3-3:2013SR3.1,SR3.5,SR3.8,SR4.1,SR4.3,SR5.1,SR5.2,SR5.3,SR
7.1,SR7.6
ISO/IEC27001:2013A.13.1.1,A.13.2.1

DNS-Based Email Security Practice Guide


DRAFT 70
Appendix C.

10
Table C.2 DETECT (DE)

Category Subcategory Informative References

Security Continuous Monitoring DE.CM-1:Thenetworkis FIPS 140-2Sec.4


(DE.CM):Theinformationsystemand monitoredtodetect SP 800-37 Rev. 13.6
assetsaremonitoredatdiscrete potentialcybersecurity
intervalstoidentifycybersecurity events NIST SP 800-45 Ver. 24.1,5.1.1,5.1.5,6.2.1,6.2.2,7.2.2
eventsandverifytheeffectivenessof NIST SP 800-53 Rev. 4AC-2,AU-12,CA-7,CM-3,SC-5,SC-7,SI-4
protectivemeasures. NIST SP 800-81-22,9,12,13
NIST SP 800-1305,6.8.5,8.2.4,9.8.4
NIST SP 800-1526.8.5,8.2.3,8.2.4,8.3,8.5
NIST SP 800-1773.1.1
CCS CSC14,16
COBIT 5DSS05.07
ISA 62443-3-3:2013SR6.2

DE.CM-6:Externalservice NIST SP 800-53 Rev. 4CA-7,PS-7,SA-4,SA-9,SI-4


provideractivityis NIST SP 800-81-22,9,12,13
monitoredtodetect
potentialcybersecurity NIST SP 800-1306.8.5,8.2.4,9.8.4,12
events NIST SP 800-1526.8.5,8.2.3,8.2.4,8.3,8.5
ISO/IEC 27001:2013A.14.2.7,A.15.2.1

Detection Process (DE.DP):Detection DE.DP-4:Eventdetection NIST SP 800-45 Ver. 29.3


processesandproceduresare informationis NIST SP 800-53 Rev. 4AU-6,CA-2,CA-7,RA-5,SI-4
maintainedandtestedtoensuretimely communicatedto
andadequateawarenessofanomalous appropriateparties NIST SP 800-1774.6
events. COBIT 5APO12.06
ISA 62443-2-1:20094.3.4.5.9
ISA 62443-3-3:2013SR6.1
ISO/IEC 27001:2013A.16.1.2

DNS-Based Email Security Practice Guide


DRAFT 71
Appendix C.

11
Table C.3 RESPOND (RS)

Category Subcategory Informative References

Response Planning (RS.RP):Response RS.RP-1:Responseplanis NIST SP 800-45 Ver. 29.3


processesandproceduresareexecuted executedduringorafteran NIST SP 800-53 Rev. 4CP-2,CP-10,IR-4,IR-8
andmaintained,toensuretimely event
responsetodetectedcybersecurity NIST SP 800-57 Part 1 Rev. 4
events. NIST SP 800-57 Part 23.1.2.1.3,3.2.2.6
NIST SP 800-1306.2.1,6.4.5,6.4.6,6.8,10.1
NIST SP 800-1526.8,10
NIST SP 800-1774.6
COBIT 5BAI01.10
CCS CSC18
ISA 62443-2-1:20094.3.4.5.1
ISO/IEC 27001:2013A.16.1.5

Communications (RS.CO):Response RS.CO-2:Eventsare NIST SP 800-45 Ver. 29.3


activitiesarecoordinatedwithinternal reportedconsistentwith NIST SP 800-53 Rev. 4AU-6,IR-6,IR-8
andexternalstakeholders,as establishedcriteria
appropriate,toincludeexternalsupport NIST SP 800-57 Part 1 Rev. 48.3.5,9.3.4,10.2.9
fromlawenforcementagencies. NIST SP 800-57 Part 23.1.2.1.2,3.2.2.10,3.2.2.14,3.2.2.15,A.1.1,A.1.4,C.2.2.12
NIST SP 800-1306.8
NIST SP 800-1526.8
NIST SP 800-1774.6
ISA 62443-2-1:20094.3.4.5.5
ISO/IEC 27001:2013A.6.1.3,A.16.1.2

DNS-Based Email Security Practice Guide


DRAFT 72
Appendix C.

Table C.3 RESPOND (RS)

Category Subcategory Informative References

Mitigation (RS.MI):Activitiesare RS.MI-1:Incidentsare NIST SP 800-53 Rev. 4IR-4


performedtopreventexpansionofan contained NIST SP 800-1306.8.1
event,mitigateitseffects,anderadicate
theincident. NIST SP 800-1526.8
ISA 62443-2-1:20094.3.4.5.6
ISA 62443-3-3:2013SR5.1,SR5.2,SR5.4
ISO/IEC 27001:2013A.16.1.5

RS.MI-2:Incidentsare NIST SP 800-53 Rev. 4IR-4


mitigated NIST SP 800-57 Part 1 Rev. 45.3,5.4,5.5,8.3.4,8.3.5
NIST SP 800-57 Part 25.3.7,5.3.8
NIST SP 800-1304.9.3,6.8,9.5,12
NIST SP 800-1523.4.2,4.5,6.8,9.5,9.8,12
ISA 62443-2-1:20094.3.4.5.6,4.3.4.5.10
ISO/IEC 27001:2013A.12.2.1,A.16.1.5

DNS-Based Email Security Practice Guide


DRAFT 73
DRAFT

NIST CYBERSECURITY PRACTICE GUIDE

DOMAIN NAME
SYSTEMS-BASED
ELECTRONIC MAIL
SECURITY
How-To Guides
For Security Engineers

Scott Rose William Barker


Santos Jha Chinedum Irrechukwu
Karen Waltermire

NISTSPECIALPUBLICATION1800-6C
DRAFT
NIST Special Publication 1800-6C NIST Cybersecurity Practice Guide

DOMAIN NAME SYSTEMS-


BASED ELECTRONIC MAIL
SECURITY
1800-6C Scott Rose
How-To Guides Information Technology Laboratory
For Security Engineers National Institute of Standards and Technology

William C. Barker
Dakota Consulting
Silver Spring, MD

Santos Jha
Chinedum Irrechukwu
The MITRE Corporation
McLean, VA

Karen Waltermire
National Cybersecurity Center of Excellence
National Institute of Standards and Technology

November2016

U.S. Department of Commerce


Penny Pritzker, Secretary

National Institute of Standards and Technology


Willie May, Under Secretary of Commerce for Standards and Technology and Director
DRAFT
DISCLAIMER
Certaincommercialentities,equipment,products,ormaterialsmaybeidentifiedinthis
documentinordertodescribeanexperimentalprocedureorconceptadequately.Such
identificationisnotintendedtoimplyrecommendationorendorsementbyNISTorNCCoE,nor
isitintendedtoimplythattheentities,equipment,products,ormaterialsarenecessarilythe
bestavailableforthepurpose.

NationalInstituteofStandardsandTechnologySpecialPublication1800-6C
NatlInst.Stand.Technol.Spec.Publ.1800-6C,144pages(November2016)
CODEN:NSPUE2

Organizationsareencouragedtoreviewalldraftpublicationsduringpubliccommentperiods
andprovidefeedback.AllpublicationsfromNISTsNationalCybersecurityCenterofExcellence
areavailableathttp://nccoe.nist.gov.

Commentsonthispublicationmaybesubmittedto:dns-email-nccoe@nist.gov

Publiccommentperiod:November2,2016throughDecember19,2016

NationalCybersecurityCenterofExcellence
NationalInstituteofStandardsandTechnology
100BureauDrive
Gaithersburg,MD20899
Mailstop2002
Email:dns-email-nccoe@nist.gov

DNS-Based Email Security Practice Guide iii


DRAFT
NATIONAL CYBERSECURITY CENTER OF EXCELLENCE
TheNationalCybersecurityCenterofExcellence(NCCoE)attheNationalInstituteofStandards
andTechnology(NIST)addressesbusinessesmostpressingcybersecurityproblemswith
practical,standards-basedsolutionsusingcommerciallyavailabletechnologies.TheNCCoE
collaborateswithindustry,academic,andgovernmentexpertstobuildmodular,open,end-to-
endreferencedesignsthatarebroadlyapplicableandrepeatable.Thecentersworkresultsin
publiclyavailableNISTCybersecurityPracticeGuides,SpecialPublicationSeries1800,that
provideuserswiththematerialslists,configurationfiles,andotherinformationtheyneedto
adoptasimilarapproach.
TolearnmoreabouttheNCCoE,visithttp://nccoe.nist.gov.TolearnmoreaboutNIST,visit
http://www.nist.gov.

NIST CYBERSECURITY PRACTICE GUIDES


NISTCybersecurityPracticeGuides(SpecialPublicationSeries1800)targetspecificcybersecurity
challengesinthepublicandprivatesectors.Theyarepractical,user-friendlyguidesthat
facilitatetheadoptionofstandards-basedapproachestocybersecurity.Theyshowmembersof
theinformationsecuritycommunityhowtoimplementexamplesolutionsthathelpthemalign
moreeasilywithrelevantstandardsandbestpractices.

Thedocumentsinthisseriesdescribeexampleimplementationsofcybersecuritypracticesthat
businessesandotherorganizationsmayvoluntarilyadopt.Thedocumentsinthisseriesdonot
describeregulationsormandatorypractices,nordotheycarrystatutoryauthority.

ABSTRACT
Thisdocumentproposesareferenceguideonhowtoarchitect,install,andconfigureasecurity
platformfortrustworthyemailexchangesacrossorganizationalboundaries.Theprojectincludes
reliableauthenticationofmailservers,digitallysigningandencryptingemail,andbinding
cryptographickeycertificatestosourcesandservers.Theexamplesolutionsandarchitectures
presentedherearebaseduponstandards-basedandcommerciallyavailableproducts.The
examplesolutionspresentedherecanbeusedbyanyorganizationimplementingDomainName
System-basedelectronicmailsecurity.

KEYWORDS
electronicmail,digitalsignature;encryption;domainnamesystem;dataintegrity;
authentication,namedentities,internetaddresses,internetprotocols,privacy

DNS-Based Email Security Practice Guide iv


DRAFT
ACKNOWLEDGMENTS
Wegratefullyacknowledgethecontributionsofthefollowingindividualsandorganizationsfor
theirgenerouscontributionsofexpertise,time,andproducts.

Name Organization

NateLesser NationalCybersecurityCenterofExcellence

KarenWaltermire NationalCybersecurityCenterofExcellence

DougMontgomery NISTITLAdvancedNetworksTechnologiesDivision

JanetJones MicrosoftCorporation

PaulFox MicrosoftCorporation

JoeGersch Secure64

SakshamManchanda Secure64

BennoOvereinder NLnetLabs

RalphDolmans NLnetLabs

WillemToorop NLnetLabs

BudBruegger FraunhoferIAO

VictoriaRisk InternetSystemsConsortium

EddyWinstead InternetSystemsConsortium

DNS-Based Email Security Practice Guide v


Contents

Contents
1 Introduction........................................................................................................................... 1
1.1 Practice Guide Structure ...............................................................................................................2
1.2 Build Overview ..............................................................................................................................3
1.3 Typographical Conventions ..........................................................................................................7

2 How to Install and Configure DNS-Protected Email Security Components .................... 8


2.1 Laboratory Set-up .........................................................................................................................9
2.2 How to Install and Configure Microsoft Server-Based DNS-Protected Email Security Components
18
2.3 How to Install and Configure BIND .............................................................................................18
2.4 NSD 4 Requirements, Installation, Setup, and Configuration Components................................24
2.5 How to Install and Configure OpenDNSSEC ..............................................................................29
2.6 Unbound .....................................................................................................................................34
2.7 How to Install and Configure a DNS Signer Platform .................................................................37
2.8 How to Install and Configure a DNS Authority Platform..............................................................37
2.9 How to Install and Configure DNS Cache ...................................................................................37
2.10 How to Install and Configure a Dovecot/Postfix Mail Transfer Agent .........................................38
2.11 How to Install and Configure a Thunderbird Mail Client..............................................................50

3 Device Configuration and Operating Recommendations ............................................... 53


3.1 Using SSL for Cryptographic Certificate Generation ..................................................................54
3.2 Cryptographic Operations (User Actions) ...................................................................................60
3.3 Server-to-Server Encryption Activation and Use ........................................................................67
3.4 Utilities and Useful Tools ............................................................................................................67

Appendix A Acronyms .......................................................................................................... 70

Appendix B References ........................................................................................................ 72

Appendix C Platform Operation and Observations............................................................ 75


C.1 Operations Scenarios ...........................................................................................................75
C.2 Test Sequences ...................................................................................................................76

Appendix D Secure Name System (DNS) Deployment Checklist...................................... 89

Appendix E Overview of Products Contributed by Collaborators.................................... 94


E.1 Open Source MUA and MTA Components ..........................................................................94
E.2 Microsoft Windows-Based Components ..............................................................................96
E.3 NLnet Labs Name Server Daemon-Based Components .....................................................98

DNS-Based Email Security Practice Guide i

DRAFT
Contents

E.4 ISC BIND Component ........................................................................................................100


E.5 Secure64 Component ........................................................................................................103

Appendix F Installation and Configuration Log for NSD4, Unbound, and OpenDNSSEC ..
106

Appendix G Microsoft Installation for the NCCoE ............................................................ 115


G.1 Microsoft Server .................................................................................................................115
G.2 Active Directory Domain Services ......................................................................................116
G.3 Active Directory Certificate Services: Microsoft Certificate Authority .................................118
G.4 Microsoft Domain Name Services: DNS Domain Server ...................................................126
G.5 Microsoft Exchange ............................................................................................................127

Appendix H Installation and Configuration of DNS Authority, DNS Cache, and DNS Signer
at the NCCoE .......................................................................................................................... 144
H.1 DNS Signer ........................................................................................................................144
H.2 DNS Authority ....................................................................................................................144
H.3 DNS Cache ........................................................................................................................144

List of Figures
Figure 1.1 DNS-Based Email Security Deployment Diagram .............................................. 6

Figure 2.1 DNS-Based Email Security Test Set-up ............................................................ 10

Figure 2.2 S/MIME and SMIMEA Deployment Flowchart ................................................... 15

Figure 2.3 TLS/TLSA Deployment Flowchart...................................................................... 16

Figure 2.4 Adding Network Users for Trustworthy Email.................................................. 17

Figure 2.5 Removing Network Users for Trustworthy Email............................................. 17

Figure 3.1 Example OpenSSL Configuration File............................................................... 57

Figure C.1 Fraudulent DNS Address Spoofing Configurations......................................... 82

Figure C.2 Man-in-the-Middle Event Configurations .......................................................... 84

Figure C.3 Failed Delivery Logs ........................................................................................... 87

DNS-Based Email Security Practice Guide ii

DRAFT
Contents

List of Tables
Table 2.1 Test Sequence 1 ...................................................................................................11

Table 2.2 Test Sequence 2 ...................................................................................................12

Table 2.3 Test Sequence 3 ...................................................................................................13

Table 2.4 Test Sequence 4 ...................................................................................................13

Table 2.5 Postfix Default Settings and Optional Features ................................................44

Table C.1 Transaction Results Based on Sender TLS/DANE Connection.......................88

DNS-Based Email Security Practice Guide iii

DRAFT
1 1 Introduction
2 1.1 Practice Guide Structure ...................................................................................................... 2
3 1.2 Build Overview ..................................................................................................................... 3
4 1.3 Typographical Conventions.................................................................................................. 7
5

DNS-Based Email Security Practice Guide DRAFT 1


Chapter 1. Introduction

6 ThefollowingguideshowsITprofessionalsandsecurityengineershowweimplemented
7 examplesolutionstothechallengeofemployingDomainNameSystemSecurityExtensions
8 (DNSSEC)1,andprotocol-baseddigitalsignatureandencryptiontechnologiestoprotect
9 electronicmail(email).Wecoveralltheproductsthatweemployedinoursolutionset.Wedo
10 notrecreatetheproductmanufacturer'sdocumentation,whichispresumedtobewidely
11 available.Rather,thisguideshowshowweincorporatedtheproductstogetherinour
12 environmenttoprovidecomposedsecurityplatforms.

13 Note: This is not a comprehensive tutorial. There are many possible service and security
14 configurations for these products that are out of scope for this reference solution set.

15 1.1 Practice Guide Structure


16 ThisNationalInstituteofStandardsandTechnology(NIST)CybersecurityPracticeGuide
17 addressesthechallengeofprovidingdigitalsignaturetechnologiestoprovideauthentication
18 andintegrityprotectionforelectronicmail(email)onanend-to-endbasis,andconfidentiality
19 protectionforemailintransitbetweenorganizations.
20 TheNISTSpecialPublication1800-6seriesofdocumentscontain:
21 rationaleforanddescriptionsofaDomainNameSystem-Based(DNS-Based)ElectronicMail
22 (Email)Securityplatformthatpermitstrustworthyemailexchangesacrossorganizational
23 boundaries
24 aseriesofHow-ToGuides,includinginstructionsforinstallationandconfigurationofthe
25 necessaryservices,thatshowsystemadministratorsandsecurityengineershowtoachieve
26 similaroutcomes
27 Thesolutionsandarchitecturespresentedarebuiltuponstandards-based,commercially
28 availableproducts.Thesesolutionscanbeusedbyanyorganizationdeployingemailservices
29 thatiswillingtoimplementcertificate-basedcryptographickeymanagementandDNSSecurity
30 Extensions(DNSSEC).Interoperablesolutionsareprovidedthatareavailablefromdifferent
31 typesofsources(e.g.,bothcommercialandopensourceproducts)andfunctionindifferent
32 operatingsystemsenvironments.
33 ThissummarysectiondescribesthechallengeaddressedbythisVolumeC(How-ToGuide)the
34 solutiondemonstratedtoaddressthechallenge,thecomponentsprovidedbyproject
35 collaboratorsthathavebeenusedtocomposethesecurityplatforms,anoverviewofhowthe
36 componentsareconfiguredtopermitconstructionofplatformsthatcrossproductlines,and
37 typographicalconventionsusedinthePracticeGuide.Section2,HowtoInstallandConfigure
38 DNS-ProtectedEmailSecurityComponents,providesmailandtransportlayersecurity
39 compositionandcomponent-centricrequirementsandrecommendationsintendedtopermit
40 usingMailUserAgent(MUA)2,MailTransferAgent(MTA)3,andDNSServicescomponentswith
41 MUAs,MTAs,andDNSServicesfromdifferentvendorsandopensources.Itincludessystem
42 requirements,installationinstructionsandadviceandspecialsettingsrequirementsassociated

1.RFC4033,DNS Security Introduction and Requirements


2.AccordingtoNISTSpecialPublication(SP)800-177,aMUAisasoftwarecomponent(orweb
interface)thatallowsanendusertocomposeandsendmessagesandtooneormorerecipients.
AMUAtransmitsnewmessagestoaserverforfurtherprocessing(eitherfinaldeliveryortrans-
fertoanotherserver).SeeSection2,Definitions,athttps://tools.ietf.org/html/rfc3888.

DNS-Based Email Security Practice Guide DRAFT 2


Chapter 1. Introduction

43 witheachoftheMUA,MTA,andDNSServicescomponents.Inmostcaseswherethe
44 componentsarecommercialproducts,linksaresimplyprovidedtovendorsites.Moredetailed
45 instructionsareprovidedfordownloading,installing,andconfiguringopen-sourceproducts.
46 Section3,DeviceConfigurationandOperatingRecommendations,providessomespecific
47 adviceandtoolstosupportsecureandsreliableintegrationandoperationofthesecurity
48 platforms.Topicsincludecertificateacquisitionandmanagementoptions,managingmail
49 transferagentoperationwheretherearesignificantnumbersofcasesofnon-deliveryof
50 messagesduetoinvaliddigitalsignatures,devicesetuprecommendations,emailsetup
51 recommendations,andmanagementofexceptionconditions.AppendixAisalistofAcronyms.
52 AppendixBprovidesreferences.AppendixCdescribestesteventsandresultsfromexercising
53 differentcombinationsofcomponentsintocomposedsecurityplatforms,includingsystem
54 responsestoattemptstosubvertDNSSECprotectionmechanisms.AppendixDisachecklistfor
55 recommendedsecuredomainnamesystemdeploymentpractices.Finally,forreaders
56 unfamiliarwithanyofthespecificcomponentsemployedbythisproject,AppendixEprovidesa
57 setofhigh-levelcollaboratorproductdescriptionsforcontributedcomponents.AppendixF
58 describesanexampleNCCoEinstallationandconfigurationofcomponentsprovidedbyour
59 NLnetLabscollaborator.AppendixGdescribesanexampleNCCoEinstallationandconfiguration
60 ofcomponentsprovidedbyourMicrosoftcollaborator.AppendixHdescribesNCCoE
61 installationandconfigurationofcomponentsprovidedbyourSecure64collaborator.

62 1.2 Build Overview

63 1.2.1 Usage Scenarios Supported


64 Thescenariossupportedinclude:
65 ordinaryemailwheretheemailexchangesbetweentwoorganizations'emailservers
66 communicateoverTransportLayerSecurity(TLS)1withaSTARTTLS2extension,andrelevant
67 TLSA3recordsarepublishedinthereceiver'sDNSzoneprotectedbyDNSSEC(Scenario1in
68 thisdocument)
69 end-to-endsignedemail,wheretheemailexchangesbetweenusersindifferent
70 organizationsarecarriedoverachannelprotectedbyTLS(usingtheSTARTTLSextension),
71 andrelevantartifactsusedforsigningandchannelprotectionarepublishedinaDNSzone
72 protectedbyDNSSEC(Scenario2).Subsequently,theseartifactsareusedfor
73 Secure/MultipurposeInternetMailExtensions(S/MIME)4andTLSvalidation.

3.AlsoaccordingtoSP800-177,mailistransmitted,inastoreandforwardfashion,acrossnet-
worksviaMailTransferAgents(MTAs).MTAscommunicateusingtheSimpleMailTransferPro-
tocol(SMTP)describedbelowandactasbothclientandserver,dependingonthesituation.See
Section2,Definitions,athttps://tools.ietf.org/html/rfc3888.
1.RFC5246,The Transport Layer Security (TLS) Protocol Version 1.2
2.SeeRFC3207,SMTP Service Extension for Secure SMTP over Transport Layer Security.
3.RFC6698,The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security
(TLS) Protocol: TLSA,ProposedStandard(August2012;Errata)UpdatedbyRFC7671,RFC7218
4.RFC2633,S/MIME Version 3 Message Specification

DNS-Based Email Security Practice Guide DRAFT 3


Chapter 1. Introduction

74 Inbothscenarios,end-entityandpersonalcertificatesweregeneratedfromCertificate
75 Authorities(CAs)1.Useofwellknown(i.e.installedastrustanchorsinhosts),localenterprise
76 CAsandself-signedcertificatesweredemonstrated.
77 Whilethesecondscenariodemonstratedsigningofemails,itdoesnotincludeanend-to-end
78 encryptedemailscenario.Signingaddressesthemainsecurityconcernsinenterprise
79 environments,whicharethetargetoftheproject,butmayneglectconcernsofindividualusers
80 whomayalsowanttoreduceinformationdisclosuretotheiremailproviders.Thetwo
81 scenariosthatareincludedmay,however,serveasenablersforend-to-endencryption.
82 Participationbypartieshavingaprimarilyend-to-endencryptionfocusmaysucceedin
83 generatingindustrysupportforthebuildingblocksneededtosupportend-to-endencryption.
84 Inmoredetail,theproject'ssecurityplatformsusetheSTARTTLSextensiontoinclude
85 encryptionofcommunicationsbetweentwoMTAs,aswellasthesignatureofindividual
86 messagesusingS/MIME.TheencryptionanddecryptionwithS/MIMEontheenduser'sclient
87 wasexcludedfromthecurrentplatformdemonstration.

88 1.2.2 Architectural Overview


89 ThelaboratoryarchitecturefortheDNSSEC-BasedEmailSecurityprojectwasdesignedto
90 permitinterconnectionofMicrosoftOutlook,AppleMail,andThunderbirdMUAswith
91 MicrosoftExchangeandPostfix/DovecotMTAs.Itdemonstratestheinterconnectionofeither
92 MTAwithvariousDNSservicescontributedbycollaborators.TwoinstantiationsofeachMTA
93 typewereestablishedtodemonstrateemailexchangesbetweenMTAsofthesametypeor
94 differenttypes.Thevariouscomponentcombinationsweredemonstratedwiththreedifferent
95 TLSARR2parameters:aself-signedcertificate,useoflocalcertificateauthorities,anduseof
96 well-knowncertificateauthorities.
97 Figure1.1isadeploymentdiagramofthearchitectureusedfordemonstratingDNS-Based
98 EmailSecurity.
99 Thefollowingsubsectionsdescribethearchitecture'sMUA,MTA,andDNSservicecomponents
100 andCybersecurityFrameworkCorecategoriessupportedbythosecomponents.Component
101 descriptionsareprovidedinAppendixEforthosenotfamiliarwithsomeoftheindividual
102 components.

1.AccordingtoNISTSP800-177,atrustedCertificateAuthority(CA)islicensedtovalidateappli-
cants'credentials,storetheirpublickeyinaX.509[RFC5280]structure,anddigitallysignitwith

theCA'sprivatekey.TLSreliesonpublickeycryptographyandusesX.509certificates[RFC5280]
toencapsulatethepublickey,andtheCAsystemtoissuecertificatesandauthenticatetheorigin
ofthekey.Anorganizationcangenerateitsownrootcertificateandgiveitsmembersacertifi-
categeneratedfromthatroot,orpurchasecertificatesforeachmemberfromawell-knownCA.
2.AccordingtoRFC6698,TheTLSADNSresourcerecord(RR)isusedtoassociateaTLSserver
certificateorpublickeywiththedomainnamewheretherecordisfound,thusformingaTLSA
certificateassociation.

DNS-Based Email Security Practice Guide DRAFT 4


Chapter 1. Introduction

103 1.2.2.1 Client Systems and Mail User Agents (MUAs)


104 ClientsystemsenvironmentsdemonstratedwereMicrosoftOffice,anopen-sourceLinux-based
105 Thunderbirdapplication,andThunderbirdwithaSecure64-providedAppleKeyChainutility.
106 Thissetincludesbothcommercialproductsandopen-sourcesoftware.MUAcapabilities
107 associatedwiththeclientsystemsareusedtoinvokeS/MIMEdigitalsignatureandsignature
108 verificationforemail,butuser-to-userencryptionisnotdemonstrated.Collaboratorsassisted
109 ininstallation,integrationtailoringasnecessary,andtestingoflaboratoryconfigurations.

110 1.2.2.2 Email Servers


111 EmailserversincludebothWindowsandLinux-based(Postfix/Dovecot)MailTransferAgents.
112 Server-to-serverencryptionwasdemonstratedinPostfixenvironments.Authenticationof
113 domainandserveridentitywasbasedonDNSSEC-signedDANErecords.UseoftheseDANE
114 recordsisonlysupportedbyPostfixatthetimeofthisproject.Theserversweredemonstrated
115 indifferentDNSenvironmentsanddifferentTLSARRusagescenarios.Inordertodemonstrate
116 representativeTLSAparameters,thedemonstrationsusedself-signedcertificates,end-entity
117 certificatesgeneratedbywell-knownCAsandend-entitiesgeneratedbyenterpriselocalCAs.

118 Figure 1.1 DNS-Based Email Security Deployment Diagram

119

DNS-Based Email Security Practice Guide DRAFT 5


Chapter 1. Introduction

120 1.2.2.3 DNS Servers


121 BothWindowsandLinux-basedDNSserverandsupportcomponentswerecontributed.DNS
122 servicesprovidedincludeDNSSECvalidatingDNSresolvers(stubandrecursive)and
123 authoritativeDNSserversforDNSSECsignedzones.1SupportforSMIMEAandTLSArecordswas
124 demonstrated.DNScomponentsincludedMicrosoft'sActiveDirectoryandDNSServer;Internet
125 SystemsConsortium's(ISC's)BerkeleyInternetNameDomain(BIND);NLnetLabs'NSD4,
126 Unbound,andOpenDNSSEC;andSecure64'sDNSSigner,DNSAuthority,DNSCache,DNS
127 Manager,andAppleKeyChainUtility.

128 1.3 Typographical Conventions


129 Thefollowingtablepresentstypographicconventionsusedinthisvolume.
130
Typeface/ Symbol Meaning Example

Italics filenamesandpathnames Fordetaileddefinitionsofterms,seethe


referencestodocumentsthatare NCCoE Glossary.
nothyperlinks,newterms,and
placeholders

Bold namesofmenus,options, ChooseFile> Edit.


commandbuttonsandfields

Monospace command-lineinput,on-screen mkdir


computeroutput,samplecode
examples,statuscodes
Monospace Bold command-lineuserinput service sshd start
contrastedwithcomputeroutput

bluetext linktootherpartsofthe AllpublicationsfromNISTsNational


document,awebURL,oranemail CybersecurityCenterofExcellenceare
address availableathttp://nccoe.nist.gov

1.https://www.ietf.org/rfc/rfc1034.txt

DNS-Based Email Security Practice Guide DRAFT 6


1 2 How to Install and Configure DNS-Protected
2 Email Security Components
3 2.1 Laboratory Set-up ................................................................................................................ 9
4 2.2 How to Install and Configure Microsoft Server-Based DNS-Protected Email Security
5 Components18
6 2.3 How to Install and Configure BIND .................................................................................... 18
7 2.4 NSD 4 Requirements, Installation, Setup, and Configuration Components....................... 24
8 2.5 How to Install and Configure OpenDNSSEC ..................................................................... 29
9 2.6 Unbound............................................................................................................................. 34
10 2.7 How to Install and Configure a DNS Signer Platform......................................................... 37
11 2.8 How to Install and Configure a DNS Authority Platform ..................................................... 37
12 2.9 How to Install and Configure DNS Cache .......................................................................... 37
13 2.10 How to Install and Configure a Dovecot/Postfix Mail Transfer Agent ................................. 38
14 2.11 How to Install and Configure a Thunderbird Mail Client..................................................... 50
15

DNS-Based Email Security Practice Guide DRAFT 8


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

16 Thissectionexplainssetupforthecomponentsetsprovidedbyprojectcollaborators.Set-upis
17 describedforavirtualmachineenvironment.Theenvironmentusedforthisprojectwasthe
18 Centos7LinuxdistributionrunningonVMware.Thissectionincludesadescriptionofthe
19 laboratoryset-upforthecapabilitydemonstrationsandflowchartsforinstallationand
20 configurationofmailsecurityandDNSsecuritycomponentsinanenterprise.Thisconfiguration
21 overviewisfollowedbysomegeneralinstructionsforinstallationandconfigurationofopen
22 sourcecomponentsareprovided,withlinkstosourcesitesformoredetailedinstructions.Less
23 generalinstallationisprovidedforcommercialcomponents,butlinksareprovidedtothe
24 vendorsites.SpecificinstallationandconfigurationinstructionsfortheNCCoEenvironmentare
25 providedasappendices(AppendixF,AppendixG,andAppendixH).

26 2.1 Laboratory Set-up


27 Thedesignoftheenvironmentpermitsinterconnectionofcomponentsprovidedbydifferent
28 collaborators(seefigure2.1).
29 Thedepictionshowsthattheprojectsecurityplatformtest/demonstrationactivitywasbased
30 onthreedifferentclients,twoMTAs,andfourDNSserviceconfigurationsinthelabatthe
31 NCCoEexchangingmessageswithNLnetLabsandSecure64.Allmessagesweresigned(amail
32 clientfunction).MessagessentviaaPostfixMTAwereencrypted(servertoserver).The
33 messageexchanges,includingDNSactivitywillbeloggedateachend(labandremote
34 correspondent).
35 Thesolidconnectorsinthedepictionillustrateonecase.Thedottedlinesdepicttheothercases
36 we'llwanttodemonstrate.Aswitchconventionisusedtoreflectconfigurationoptions,butthe
37 projectteamactuallyconfigureseachcomponentforeachoption.
38 TheorangearrowsbetweenthemailclientsandthePostfixMTAreflectthefactthatclients
39 submittedemaildirectlytotheSMTPserverforrelay,whileusingDovecotonlytogetmail.(The
40 depictioninfigure2.1reflectsthatIMAPisn'tusedtosubmitmail,onlyretrieveit,sotheMUA
41 sentmaildirectlytothePostfixserver,butreceivedthereplythroughtheDovecotserver.)

DNS-Based Email Security Practice Guide DRAFT 9


42 Figure 2.1 DNS-Based Email Security Test Set-up

43

44 Theprojectteamdemonstrated30differenteventsusingvariouscombinationsofMUA,MTA,andDNSServercomponentsdivided
45 amongfivetestsequences.Ineachsequence,signedandencryptedmessagesweresentfromasendertoarecipient.Postfixencrypted
46 mailbydefault.Mostoftheexchangesemployedeitherself-signedcertificatesorlocalCAs(seeAppendixC).TheBINDconfiguration
47 wassetuptoobtainandvalidatecertificatesfromtheNISTAdvancedNetworksTechnologyDivision's(ANTD's)DNSsource(actingasa
48 rootCA).

DNS-Based Email Security Practice Guide


DRAFT 10
Chapter 2. How to Install and Configure DNS-Protected Email Security Components

49 2.1.1 Sequence 1 Set-up


50 Sequence1demonstrateduseofwell-knownCAissuedcryptographiccertificates(CU=1),
51 enterpriseCAissuedcertificates(CU=2),andself-signedcertificates(CU=3)withan
52 Outlook/Exchange/ActiveDirectoryandOutlook/Exchange/BINDMUA/MTA/DNSServerstack.1
53 MailwasexchangedbetweentheNCCoEandtworemotesites.Thefirstsite,Secure64inFt
54 Collins,Colorado,usedaThunderbirdMUAwithautilityforMacBookthatcanfetchSMIMEA
55 recordsandputthemintoakeystore,aPostfixMTA,andSigner/Authority/CacheDNSservers.
56 TheNLnetsiteusedanIntel-hostedThunderbirdMUA,aPostfix/DovecotMTA,NSD4and
57 Unboundforprocessingreceivedmessages,andOpenDNSSECforoutboundmessages.All
58 messageswereS/MIMEsigned(Scenario2only).
59
Table 2.1 Test Sequence 1

Sequence
NCCoE Lab Remote Sites Certificate on
1
Receiver Side
Event MUA MTA DNS Service Secure64 and NLnet Labs

1 Outlook Exchange ActiveDirectory EnterpriseCAissued(CU=2) Well-knownCAissued


/DNSServer (CU=1)

2 Outlook Exchange ActiveDirectory Sameas1 LocalCAissued


/DNSServer (CU=2)

3 Outlook Exchange ActiveDirectory Sameas1 Self-SignedCert


/DNSServer (CU=3)

4 Outlook Exchange BIND Sameas1 Well-knownCAissued


(CU=1)

5 Outlook Exchange BIND Sameas1 LocalCAissued


(CU=2)

6 Outlook Exchange BIND Sameas1 Self-Cert(CU=3)

60 2.1.2 Sequence 2 Set-up


61 Sequence2demonstrateduseofanOutlook/PostfixMUA/MTAconfigurationwithaBINDDNS
62 Server,andaThunderbird/PostfixMUA/MTAconfigurationwithbothBINDandDNS
63 Signer/Authority/Cacheset-ups.Allthreecertificateusageapproachesweredemonstrated.
64 MailwasexchangedbetweentheNCCoEandbothSecure64andNLnetLabssites.Asin
65 Sequence1,thesecure64siteusedaThunderbirdMUA,aPostfixMTA,and
66 OpenDNSSEC/Unbound/NSD4DNSservers;andtheNLnetLabssiteusedaThunderbirdMUA,a

1.Theintegrityofcryptographiccertificatesisgenerallycheckedbyverifyingadigitalsignature
generatedforthecertificatebyitssource.Certificatesmaybeself-signedbyanentitythatboth
generatesandusesit,signedbytheparententerprisethatisresponsibleforgeneratingandus-
ingthecertificate,orbesignedbysomewell-knownthirdpartycertificatesourcethatistrust-
ed by organizations using the certificates for cryptographic protection processes. Certificate
usageisdesignatedCU=1forcertificatesissuedbywell-knownCAs,CU=2forcertificatesis-
suedbyenterpriseCAs(alsoknownasLocalCAs),andCU=3forcertificatesthatareself-signed.
CU=1isgenerallyconsideredmosttrustworthy,andCU=3isconsideredleasttrustworthy.

DNS-Based Email Security Practice Guide DRAFT 11


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

67 Postfix/DovecotMTA,NSD4andUnboundforDNSprocessingreceivedmessages,and
68 OpenDNSSECforoutboundmessages.EmailmessagesbetweenMTAswereencryptedand
69 successfullydecryptedviaTLS;anintermediateprocessorverifiedthatencryptionoccurred;
70 inspectionofthereceivedmessageverifiedthatdecryptionwassuccessful;
71 encryption/decryptionresultswerenoted;andallmessageswereS/MIMEsigned(Scenarios1
72 and2).
73
Table 2.2 Test Sequence 2

Sequence Certificate
NCCoE Lab Remote Sites
2 on Receiver
Event MUA MTA DNS Service Secure64 and NLnet Labs Side

7 Outlook Postfix/ BIND Thunderbird,Postfix/Dovecot, Well-known


Dovecot NSD4/Unbound/OpenDNSSEC CAissued
Self-SignedCert(CU=3) (CU=1)

8 Thunderbird Postfix/ BIND Sameas7 LocalCA


Dovecot issued(CU=2)

9 Thunderbird Postfix/ BIND Sameas7 Self-Signed


Dovecot Cert(CU=3)

10 Thunderbird Postfix/ DNSAuthority/ Sameas7 Well-known


Dovecot Cache/Signer CAissued
(CU=1)

11 Thunderbird Postfix/ DNSAuthority/ Sameas7 LocalCA


Dovecot Cache/Signer issued(CU=2)

12 Thunderbird Postfix/ DNSAuthority/ Sameas7 Self-Cert


Dovecot Cache/Signer (CU=3)

74 2.1.3 Sequence 3 Set-up


75 Sequence3usedanOutlook/Exchange/ActiveDirectorystacktoposeastheremotesuiteused
76 inSequence1andattempttospoofanOutlook/ExchangeActiveDirectorystackanda
77 Thunderbird/PostfixconfigurationservedbyeachofthreeDNSservertypes
78 (OpenDNSSEC/NSD4/Unbound,DNSSigner/Authority/Cache,andBIND).Alleventswere
79 conductedusingwell-knownCAandEnterpriseCA-issuedcertificatesfortheimpersonated
80 sender.TheemailexchangebetweenorganizationswascarriedoverTLS,andtheemail
81 messagewasS/MIMEsignedonthefraudulentusers'clientdevice.

DNS-Based Email Security Practice Guide DRAFT 12


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

82
Table 2.3 Test Sequence 3

Sequence Certificate
NCCoE Lab Remote Sites
3 on Receiver
Event MUA MTA DNS Service Secure64 and NLnet Labs Side

13 Outlook Exchange ActiveDirectory ThunderbirdonMacBook, LocalCA


Postfix/Dovecot,DNS (CU=1)
Authority/Cache/SignerLocal
CAissued(CU=2)

14 Thunderbird Postfix/ NSD4/ Sameas13 LocalCA


Dovecot Unbound/ issued(CU=1)
OpenDNSSEC

15 Thunderbird Postfix/ DNSAuthority/ Sameas13 LocalCA


onMacBook Dovecot Cache/Signer issued(CU=1)

16 Outlook Exchange ActiveDirectory Sameas13 Self-Signed


Cert(CU=3)

17 Thunderbird Postfix/ NSD4/Unbound/ Sameas13 Self-Signed


Dovecot OpenDNSSEC Cert(CU=3)

18 Thunderbird Postfix/ BIND Sameas13 Self-Cert


Dovecot (CU=3)

83 2.1.4 Sequence 4 Set-up


84 AttemptsweremadetosendaTLSprotectedemailfromExchangeandPostfixMTAs(inturn)to
85 anexternalPostfixMTAusingDNSAuthority/Cache/SignerforDNSservices.TheNCCoE
86 ExchangeMTAusedActiveDirectoryDNSServices,andthePostfix/DovecotMTAusesBIND,
87 NSD4/Unbound/OpenDNSSEC,andDNSSigner/Authority/CacheDNSservices.AnS/MIME
88 signedemailwassenttoanexternalPostfixMTA.EventswereconductedusingWell-KnownCA
89 issuedcertificates,eventsusingEnterpriseCAissuedcertificates(TLSA/SMIMEARRparameter
90 ofCU=2)forTLSandS/MIMEonthereceiverside,andthreeusingself-signedcertificates
91 (TLSA/SMIMEARRparameterofCU=3)forTLSandS/MIMEonthereceiverside.An
92 Outlook/Exchange/ActiveDirectorystackactedasaman-in-the-middleandattemptedto
93 impersonatethelegitimatereceiver.
94
Table 2.4 Test Sequence 4

Sequence Certificate
NCCoE Lab
3 Legitimate Remote Site on Receiver
Event MUA MTA DNS Service Side

19 Outlook Exchange ActiveDirectory Secure64 Well-Known


CA(CU=1)

20 Thunderbird Exchange BIND Secure64 Well-Known


CA(CU=1)

21 Thunderbird Postfix NSD4/Unbound/ Secure64 Well-Known


OpenDNSSEC CA(CU=1)

DNS-Based Email Security Practice Guide DRAFT 13


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

Table 2.4 Test Sequence 4

Sequence Certificate
NCCoE Lab
3 Legitimate Remote Site on Receiver
Event MUA MTA DNS Service Side

22 Thunderbird Postfix/ DNSAuthority/ Secure64 Well-Known


onMacBook Dovecot Cache/Signer CA(CU=1)

23 Outlook Exchange ActiveDirectory Secure64 LocalCA


(CU=2)

24 Thunderbird Postfix/ BIND Secure64 LocalCA


Dovecot (CU=2)

25 Thunderbird Postfix/ NSD4/Unbound/ Secure64 LocalCA


onMacBook Dovecot OpenDNSSEC (CU=2)

26 Thunderbird Postfix/ DNSAuthority/ Secure64 LocalCA


onMacBook Dovecot Cache/Signer (CU=2)

27 Thunderbird Postfix/ ActiveDirectory Secure64 Self-Cert


Dovecot (CU=3)

28 Thunderbird Exchange BIND Secure64 Self-Cert


(CU=3)

29 Thunderbird Postfix/ NSD4/Unbound/ Secure64 Self-Cert


onMacBook Dovecot OpenDNSSEC (CU=3)

95 2.1.5 Sequence 5 Set-up


96 ThissequenceusedanAuthoritativeDNSServer,aDANE-awarePostfixserver,andfour
97 ExchangeMTAs(eachsetupdifferently).OneranwithoutTLSA,onehadgoodTLSAanda
98 self-signedcertificate(CU=3),onehadbadPKIXandacertificatefromawell-knownCA(CU=1),
99 andonehadabadTLSAwithaself-signedcertificate(CU=3).AscriptrunningonthePostfix
100 servergeneratesamessagestream.LogsoffailedDNSeventswereexamined.

101 2.1.6 How to Deploy SMIMEA and TLSA Software for Trustworthy Email
102 Set-upforthetestsequencesrequireddeployingSMIMEAandTLSA,andaddingcertificatesand
103 recordsforusers.Figures3and4areflowchartsdepictingthestepsrequiredforinstallation
104 andconfigurationofMUAs,MTAs,andDNSserversnecessarytotrustworthyemail.Figure2.2
105 depictstheprocessforsettingupsecure/multipurposeInternetmailextensions(S/MIMEand
106 SMIMEA).Figure2.3depictstheprocessforsettinguptransportlayersecurity(i.e.,TLSand
107 TLSA).ThefiguresassumethattheenterprisehasdeployedDNSSEC,includingDANE-aware
108 components.Thefiguresincludequestionsregardingtheinstallationandconfigurationstatus
109 ofcomponents,andprovidesrecommendationsbasedontheanswerstothosequestions.
110 TogetherwiththeSecureNameSystem(DNS)DeploymentChecklistprovidedasAppendixD,
111 theseflowchartsareintendedtofacilitateestablishmentofatrustworthyemailcapabilityina
112 widerangeofenvironments.

DNS-Based Email Security Practice Guide DRAFT 14


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

113 Figure 2.2 S/MIME and SMIMEA Deployment Flowchart

114

DNS-Based Email Security Practice Guide DRAFT 15


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

115 Figure 2.3 TLS/TLSA Deployment Flowchart

116

117 2.1.7 Adding and Removing Network Users


118 Addinguserstonetworkswithtrustworthyemailenabledinvolvesidentitymanagement
119 administrative,DNSadministrative,andendusersupportactivities.Figure2.4depictsthe
120 processforgeneratingusernetworkidentities,newS/MIMECertificatesforusers,andSMIMEA
121 resourcerecords;publishingtherecordsintheDNS,andconfiguringusers'MUAstouse
122 S/MIMEkeys.

DNS-Based Email Security Practice Guide DRAFT 16


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

123 Figure 2.4 Adding Network Users for Trustworthy Email

124

125 Whenauserleavesanorganizationoraccesstonetworkresourcesisrevokedforotherreasons,
126 itisnecessarytorevokethecredentialsthatassociatetheuserwiththeorganization.This
127 actionrequiresthenetworkorsystemadministratortodisabletheuser'snetworkID,revoke
128 theuser'sS/MIMEcertificates,andarchivethecertificatesandassociatedkeys;andrequires
129 theDNSadministratortoremovetheuser'sSMIMEAresourcerecords(RRs).Figure2.5depicts
130 theflowforthisprocess.

131 Figure 2.5 Removing Network Users for Trustworthy Email

132

DNS-Based Email Security Practice Guide DRAFT 17


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

133 2.2 How to Install and Configure Microsoft Server-Based


134 DNS-Protected Email Security Components
135 Outlook,Exchange,ActiveDirectory,andDNSServerarecommercialproductsthatcanbe
136 accessedfromMicrosoft'sweb(e.g.,https://www.microsoft.com/en-us/).Outlookisgenerally
137 bundledinMicrosoftOffice(e.g.,Office365forWindows10),andDNSServerisbundledin
138 MicrosoftServersystems(e.g.,Server2016).ActiveDirectorytoolsandapplicationsarenot
139 installedinWindows10bydefault,butinstructionsregardinghowtogetthemcanbefoundat
140 http://www.technipages.com/windows-install-active-directory-users-and-computers.DNS
141 ServerisbundledwithServer2016.PleasenotethatIPaddresses,domainnames,andmail
142 addressesare,inmanycases,specifictotheNCCoElaboratoryconfigurationandmustnotbe
143 usedinactualimplementations.

144 2.2.1 Installation Basics and System Requirements


145 Systemrequirementsareproduct-specific,andinstallationinstructionsarehighlydependentof
146 version,intendedconfiguration,andtoolssetemployed.Theinstallationprocess,tools
147 employed,andconfigurationprocessfollowedinsettinguptheNCCoEMicrosoftcomponents
148 areprovidedasAppendixGtothisPracticeGuide.Manualpagesareprovidedforindividual
149 applicationsofproductsandtools(e.g.,
150 https://technet.microsoft.com/en-us/library/bb245702(v=exchg.80).aspxand
151 https://technet.microsoft.com/en-us/library/bb123543(v=exchg.141).aspxforExchange,
152 https://technet.microsoft.com/en-us/library/dn626158(v=exchg.150).aspxforOutlook),and
153 https://technet.microsoft.com/en-us/library/cc732284(v=ws.11).aspxforconfiguringaDNS
154 serverforusewithActiveDirectorydomainservices;andfromawidevarietyofthirdparty
155 sources.

156 2.2.2 Installation of Active Directory, Server, and Exchange in the NCCoE
157 Configuration
158 AppendixGdescribesinstallationandconfigurationofActiveDirectory,Server,andExchangeat
159 theNCCoE.

160 2.3 How to Install and Configure BIND1


161 ThecurrentguideforgettingstartedwithBINDandinstructiononhowtobuildandrunnamed
162 withabasicrecursiveconfigurationcanbefoundat
163 https://kb.isc.org/article/AA-00768/46/Getting-started-with-BIND-how-to-build-and-run-nam
164 ed-with-a-basic-recursive-configuration.html.ThecurrentBIND9ReferenceManualcanbe
165 foundathttps://www.isc.org/wp-content/uploads/2014/01/Bv910ARM.pdf&hl=en_US.An
166 overviewofinstallationandconfigurationbasicsfollow.PleasenotethatIPaddresses,domain
167 names,andmailaddressesare,inmanycases,specifictotheNCCoElaboratoryconfiguration
168 andmustnotbeusedinactualimplementations.

DNS-Based Email Security Practice Guide DRAFT 18


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

169 2.3.1 Installation Basics and System Requirements


170 TheNCCoEBINDinstallationwasbasedonCentos7.ISCspecifiesthatBIND9currentlyrequires
171 aUNIXsystemwithanANSICcompiler,basicPOSIXsupport,anda64bitintegertype.
172 ISChasalsohadsuccessinbuildingandtestingonthefollowingsystems:
173 COMPAQTru64UNIX5.1B
174 FedoraCore6
175 FreeBSD4.10,5.2.1,6.2
176 HP-UX11.11
177 MacOSX10.5
178 NetBSD3.x,4.0-beta,5.0-beta
179 OpenBSD3.3andup
180 Solaris8,9,9(x86),10
181 Ubuntu7.04,7.10
182 WindowsXP/2003/2008
183 ISCalsohasrecentreportsfromtheusercommunitythatasupportedversionofBINDwillbuild
184 andrunonthefollowingsystems:
185 AIX4.3,5L
186 CentOS4,4.5,5
187 Darwin9.0.0d1/ARM
188 Debian4,5,6
189 FedoraCore5,7,8
190 FreeBSD6,7,8
191 HP-UX11.23PA
192 MacOSX10.5,10.6,10.7
193 RedHatEnterpriseLinux4,5,6
194 SCOOpenServer5.0.6
195 Slackware9,10
196 SuSE9,10

197 Note: As of BIND 9.5.1, 9.4.3, and 9.3.6, older versions of Windows, including Windows NT and
198 Windows 2000, are no longer supported.

1. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit
(http://www.openssl.org/),cryptographicsoftwarewrittenbyEricYoung(eay@cryptsoft.com),andsoft-
warewrittenbyTimHudson(tjh@cryptsoft.com).

DNS-Based Email Security Practice Guide DRAFT 19


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

199 InformationregardingdownloadingBINDcanbefoundat
200 https://www.isc.org/downloads/bind/

201 2.3.2 BIND Installation and Configuration


202 ISC'srecommendedlinkforBINDstarterinformationis:
203 https://kb.isc.org/article/AA-00768/46/Getting-started-with-BIND-how-to-build-and-run-nam
204 ed-with-a-basic-recursive-configuration.html.Forauthoritativeconfiguration,refertothe
205 BIND9ARM(https://www.isc.org/downloads/bind/doc/bind-9-10/).
206 Tobuild,justenter:
207 ./configure
208 make

209 Donotuseaparallelmake.

210 2.3.2.1 Environmental Variables


211 SeveralBINDenvironmentvariablesthatcanbesetbeforerunningconfigurewillaffect
212 compilation:
213 CC
214 TheCcompilertouse.configuretriestofigureouttherightoneforsupportedsystems.
215 CFLAGS
216 Ccompilerflags.Defaultstoinclude-gand/or-O2assupportedbythecompiler.Please
217 include'-g'ifyouneedtosetCFLAGS.
218 STD_CINCLUDES
219 Systemheaderfiledirectories.Canbeusedtospecifywhereadd-onthreadorIPv6support
220 is,forexample.STD_CINCLUDESdefaultstoemptystring.
221 STD_CDEFINES
222 Anyadditionalpreprocessorsymbolsyouwantdefined.STD_CDEFINESdefaultstoempty
223 string.
224 Possiblesettings:
225 Changethedefaultsyslogfacilityofnamed/lwresd.
226 -DISC_FACILITY=LOG_LOCAL0
227 EnableDNSSECsignaturechasingsupportindig.
228 -DDIG_SIGCHASE=1 (sets -DDIG_SIGCHASE_TD=1 and
229 -DDIG_SIGCHASE_BU=1)
230 Disabledroppingqueriesfromparticularwellknownports.
231 -DNS_CLIENT_DROPPORT=0
232 Siblinggluecheckinginnamed-checkzoneisenabledbydefault.

DNS-Based Email Security Practice Guide DRAFT 20


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

233 Todisablethedefaultcheckset.-DCHECK_SIBLING=0.
234 named-checkzonechecksout-of-zoneaddressesbydefault.
235 Todisablethisdefaultset-DCHECK_LOCAL=0.
236 Tocreatethedefaultpidfilesin${localstatedir}/runratherthan
237 ${localstatedir}/run/{named,lwresd}/set-DNS_RUN_PID_DIR=0
238 EnableworkaroundforSolariskernelbugabout/dev/poll
239 -DISC_SOCKET_USE_POLLWATCH=1
240 Thewatchtimeoutisalsoconfigurable,e.g.,
241 -DISC_SOCKET_POLLWATCH_TIMEOUT=20
242 LDFLAGS
243 Linkerflags.Defaultstoemptystring.

244 2.3.2.2 Cross Compiling


245 Thefollowingneedtobesetwhencrosscompiling:
246 BUILD_CC
247 ThenativeCcompiler.
248 BUILD_CFLAGS(optional)
249 BUILD_CPPFLAGS(optional)
250 PossibleSettings:
251 -DNEED_OPTARG=1(optargisnotdeclaredin<unistd.h>).
252 BUILD_LDFLAGS(optional)
253 BUILD_LIBS(optional)

254 2.3.2.3 Multithreading Support


255 Onmostplatforms,BIND9isbuiltwithmultithreadingsupport,allowingittotakeadvantageof
256 multipleCPUs.Youcanconfigurethisbyspecifying--enable-threadsor--disable-threads
257 ontheconfigurecommandline.Thedefaultistoenablethreads,exceptonsomeolder
258 operatingsystemsonwhichthreadsareknowntohavehadproblemsinthepast.

259 Note: Prior to BIND 9.10, the default was to disable threads on Linux systems; this has been
260 reversed. On Linux systems, the threaded build is known to change BIND's behavior with
261 respect to file permissions; it may be necessary to specify a user with the -u option when running
262 named.

263 2.3.2.4 Shared Libraries


264 Tobuildsharedlibraries,specify--with-libtoolontheconfigurecommandline.

DNS-Based Email Security Practice Guide DRAFT 21


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

265 2.3.2.5 Large Servers


266 CertainBINDcompiled-inconstantsanddefaultsettingscanbeincreasedtovaluesbetter
267 suitedtolargeserverswithabundantmemoryresources(e.g,64-bitserverswith12Gormore
268 ofmemory)byspecifying--with-tuning=largeontheconfigurecommandline.Thiscan
269 improveperformanceonbigservers,butwillconsumemorememoryandmaydegrade
270 performanceonsmallersystems.

271 2.3.2.6 DNSSEC Support


272 FortheBINDservertosupportDNSSEC,youneedtobuilditwithcryptosupport.Youmusthave
273 OpenSSL0.9.5aornewerinstalledandspecify--with-opensslontheconfigurecommand
274 line.IfOpenSSLisinstalledunderanonstandardprefix,youcantellconfigurewheretolookfor
275 itusing--with-openssl=/prefix.

276 2.3.2.7 HTTP Statistics Channel Support


277 TosupporttheHTTPstatisticschannel,theBINDservermustbelinkedwithatleastoneofthe
278 following:libxml2(http://xmlsoft.org)orjson-c(https://github.com/json-c).Iftheseare
279 installedatanonstandardprefix,use--with-libxml2=/prefixor--with-libjson=/prefix.
280 TosupportcompressionontheHTTPstatisticschannel,theservermustbelinkedagainstlibzlib
281 (--with-zlib=/prefix).

282 2.3.2.8 Python Support


283 Pythonrequires'argparse'and'ply'tobeavailable.'argparse'isastandardmoduleasof
284 Python2.7andPython3.2.

285 2.3.2.9 Files Larger than 2GB


286 Onsomeplatformsitisnecessarytoexplicitlyrequestlargefilesupporttohandlefilesbigger
287 than2GB.Thiscanbedoneby--enable-largefileontheBINDconfigurecommandline.

288 2.3.2.10 Fixed rrset-order Option


289 Supportforthefixedrrset-orderoptioncanbeenabledordisabledbyspecifying
290 --enable-fixed-rrsetor--disable-fixed-rrsetontheBINDconfigurecommandline.The
291 defaultisdisabled,toreducememoryfootprint.

292 2.3.2.11 IPv6 Support


293 IfyouroperatingsystemhasintegratedsupportforIPv6,itwillbeusedautomatically.Ifyou
294 haveinstalledKAMEIPv6separately,use--with-kame[=PATH]tospecifyitslocation.

295 2.3.2.12 Installing named and BIND 9 Libraries


296 Themake installtoolwillinstallnamedandthevariousBIND9libraries.Bydefault,installation
297 isinto/usr/local,butthiscanbechangedwiththe--prefixoptionwhenrunningconfigure.

DNS-Based Email Security Practice Guide DRAFT 22


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

298 2.3.2.13 Directory Setting Options


299 Youmayspecifytheoption--sysconfdirtosetthedirectorywhereconfigurationfileslike
300 named.confgobydefault,and--localstatedirtosetthedefaultparentdirectoryof
301 run/named.pid.ForbackwardscompatibilitywithBIND8,--sysconfdir defaultsto/etcand
302 --localstatedirdefaultsto/varifno--prefixoptionisgiven.Ifthereisa-prefixoption,
303 sysconfdirdefaultsto$prefix/etcandlocalstatedirdefaultsto$prefix/var.

304 2.3.2.14 Other Configure Options


305 Toseeadditionalconfigureoptions,runconfigure --help.Notethatthehelpmessagedoes
306 notreflecttheBIND8compatibilitydefaultsforsysconfdirandlocalstatedir.Ifyou're
307 planningonmakingchangestotheBIND9source,youshouldalsomake depend.Ifyou'reusing
308 Emacs,youmightfindmake tagshelpful.

309 2.3.2.15 Re-running Configure


310 Ifyouneedtore-runconfigurepleaserunmake distcleanfirst.Thiswillensurethatallthe
311 optionchangestake.

312 2.3.2.16 Building with gcc


313 Buildingwithgccisnotsupported,unlessgccisthevendor'susualcompiler(e.g.thevarious
314 BSDsystems,Linux).

315 2.3.2.17 Known Compiler and OS Issues


316 Knowncompilerissuesincludethefollowing:
317 gcc-3.2.1andgcc-3.1.1isknowntocauseproblemswithsolaris-x86.
318 gccpriortogcc-3.2.3ultrasparcgeneratesincorrectcodeat-02.
319 gcc-3.3.5powerpcgeneratesincorrectcodeat-02.
320 Irix,MipsPRO7.4.1misknowntocauseproblems.
321 SunOS4requiresprintftobeinstalledtomakethesharedlibraries.
322 sh-utils-1.16providesaprintfwhichcompilesonSunOS4.
323 Linuxrequireskernel

324 2.3.3 Testing


325 AlimitedBINDtestsuitecanberunwithmake test.Manyofthetestsrequireyoutoconfigure
326 asetofvirtualIPaddressesonyoursystem,andsomerequirePerl.(See
327 bin/tests/system/READMEfordetails).

328 2.3.4 BIND Documentation


329 TheBIND9AdministratorReferenceManualisincludedwiththesourcedistributionin
330 DocBookXMLandHTMLformat,inthedoc/armdirectory.

DNS-Based Email Security Practice Guide DRAFT 23


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

331 SomeoftheprogramsintheBIND9distributionhavemanpagesintheirdirectories.In
332 particular,thecommandlineoptionsofnamedaredocumentedin/bin/named/named.8.
333 Thereisnowalsoasetofmanpagesforthelwreslibrary.
334 ForupgradingfromBIND8,pleasereadthemigrationnotesindoc/misc/migration.Ifyouare
335 upgradingfromBIND4,readdoc/misc/migration-4to9.
336 FrequentlyaskedquestionsandtheiranswerscanbefoundinFAQ.
337 AdditionalinformationonvarioussubjectscanbefoundintheotherREADMEfiles.

338 2.3.5 BIND Support


339 AlthoughBINDisopensourcesoftware,supportisavailablefromISC.

340 2.4 NSD 4 Requirements, Installation, Setup, and


341 Configuration Components
342 ThelinksforNSD4.1.13tarfiles,manualpages,andSVNrepositorycanbefoundat
343 https://www.nlnetlabs.nl/projects/nsd/.Thisrepositoryprovidesfordownloadingofthelatest
344 NSD4version.NSD4canbeinstalledonUnix-basedsystems(e.g.,FreeBSD,OpenBSD,NetBSD,
345 MacOSX,andSolaris),includingLinuxsystemssuchasRedHatEnterprise,Centos,Debian,
346 Ubuntu,andGentoo.PleasenotethatIPaddresses,domainnames,andmailaddressesare,in
347 manycases,specifictotheNCCoElaboratoryconfigurationandmustnotbeusedinactual
348 implementations.

349 2.4.1 NSD 4 Installation Basics


350 NSD4isavailableindistributionrepositoriessuchthatapackagemanagercaninstallitwitha
351 singlecommand:
352 ForRedHatEnterpriseandCentos(Centos7wasusedintheNCCoEexample):
353 yum install nsd

354 ForDebianandUbuntu:
355 sudo apt-get install nsd

356 ForGentoo:
357 emerge nsd

358 2.4.2 NSD 4 Configuration (nsd.conf)


359 DifferentpathsexistforNSD4(nsd.conf).Theirpathsdependonyourdistribution:
360 Centos-RedHatEnterprise:/etc/nsd/nsd.conf
361 Debian-Ubuntu:/etc/nsd/nsd.conf

DNS-Based Email Security Practice Guide DRAFT 24


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

362 2.4.2.1 Master Configuration


363 ThefollowingisamasterconfigurationforNSD4foraCentossystem.Thisexampleshowsnsd4
364 servingthedomaindnslabs.dnsops.govontheIPaddress129.6.45.38.Thelogfilefortheactual
365 NCCoEinstallationandconfigurationofNSD4withUnboundandOpenDNSSECforthe
366 DNS-BasedEmailSecurityprojectisprovidedasAppendixF.
367 #
368 # nsd.conf -- the NSD(8) configuration file, nsd.conf(5).
369 #
370 # Copyright (c) 2001-2011, NLnet Labs. All rights reserved.
371 #
372 # See LICENSE for the license.
373 #
374

375 # This is a configuration file commented out, you just need to change
376 the IP and the zone file to customize it.
377

378 # options for the nsd server


379 server:
380 # uncomment to specify specific interfaces to
381 bind (default wildcard interface).
382 # ip-address: localhost
383 ip-address: 129.6.45.38
384

385 # don't answer VERSION.BIND and VERSION.SERVER


386 CHAOS class queries
387 # Keep yes for security reasons.
388 hide-version: yes
389

390 # enable debug mode, does not fork daemon process into the background.
391 # debug-mode: no
392

393 # do-ip4
394 default: yes
395

396 # do-ip6
397 default: yes
398

399 # Enable IPv6 as advice.


400

401 # the database to use, this is the standard path.


402 # disable database mode. Explicitly set database: ""
403 # database: ""
404

DNS-Based Email Security Practice Guide DRAFT 25


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

405 # identify the server (CH TXT ID.SERVER entry).


406 identity: ""
407

408 # NSID identity (hex string). default disabled.


409 # nsid: "aabbccdd"
410

411 # log messages to file. Default to stderr and


412 syslog (with facility LOG_DAEMON).
413 # logfile: "/var/log/nsd.log"
414

415 # Number of NSD servers to fork, keep 1 for low


416 memory VPS
417 server-count: 1
418

419 # Maximum number of concurrent TCP connections


420 per server.
421 # This option should have a value below 1000, 10
422 is good for a low memory VPS
423 tcp-count: 10
424

425 # Maximum number of queries served on a single


426 TCP connection.
427 # By default 0, which means no maximum.
428 # tcp-query-count: 0
429

430 # Override the default (120 seconds) TCP timeout.


431 # tcp-timeout: 120
432

433 # Preferred EDNS buffer size for IPv4.


434 # ipv4-edns-size: 4096
435

436 # Preferred EDNS buffer size for IPv6.


437 # ipv6-edns-size: 4096
438

439 # File to store pid for nsd in.


440 # pidfile: "/var/run/nsd/nsd.pid"
441

442 # port to answer queries on. default is 53.


443 # port: 53
444

445 # statistics are produced every number of


446 seconds.
447 # statistics: 3600

DNS-Based Email Security Practice Guide DRAFT 26


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

448

449 # if per zone statistics is enabled, file to


450 store statistics.
451 # zone-stats-file: "/var/log/nsd.stats"
452

453 # The directory for zonefile: files.


454 zonesdir: "/etc/nsd/zones"
455

456 #This is the definition of the first zone, you


457 must have 1 for every domain.
458 zone:
459 name: dnslabs.dnsops.gov
460 #file in the zonesdir that contains the domain
461 information.
462 zonefile: dnslabs.dnsops.gov.conf
463

464 # See https://www.nlnetlabs.nl/projects/nsd/nsd-control.8.html for


465 nsd-control config

466 2.4.2.2 NSD Zone File


467 Thenextstepissettingupzonefiles.Thefollowinginstructionssetupasimplezonefilethat
468 justdefinestheSOA,theNS,MXandsomeaddressforthedomain:
469 ;## NSD authoritative only DNS
470

471 $ORIGIN dnslabs.dnsops.gov. ; default zone domain


472 $TTL 86400 ; default time to live
473

474 @ IN SOA nev1 admin@dnslabs.dnsops.gov (


475 2012082703 ; serial number
476 28800 ; Refresh
477 14400 ; Retry
478 864000 ; Expire
479 86400 ; Min TTL
480 )
481

482 NS nev1.dnslabs.dnsops.gov .
483 NS nev2.dnslabs.dnsops.gov .
484 MX 10 mail.dnslabs.dnsops.gov .
485

486 mail IN A 129.6.45.38


487 www IN A 129.6.45.38
488 nev1 IN A 129.6.45.38
489 nev2 IN A 129.6.45.38

DNS-Based Email Security Practice Guide DRAFT 27


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

490 * IN A 129.6.45.38
491 @ IN A 129.6.45.38
492

493 ;## NSD authoritative only DNS


494

495 ForNSDitisarequisitetosetyourNSnameserverhostname(nev1.dnslabs.dnsops.govto
496 129.6.45.38inthisexample)tothesameIPaddressNSDislisteningon,theonewehavesetin
497 thensd.conffile.ThisissoimportantbecausearesolvingDNSserver,likeBIND,willaskNSD
498 whatthecurrentauthoritativenameserverIPaddressis.NSDwillsaythenameserverfor
499 dnslabs.dnsops.govisnev1.dnslabs.dnsops.govanditsIPis129.6.45.38.Andso
500 129.6.45.38istheaddressthatanotherservicelikeBINDwillusetoconnect.
501 * IN A 129.6.45.38

502 includesthenamesinthedomain.dnslabs.dnsops.gov.

503 2.4.2.3 Compile the NSD Database and Start Daemon

504 Note: NLnet Labs advises against running NSD4 in the database mode unless there is a
505 compelling local reason.

506 1. General
507 Nsd-control stop/start
508 2. RestartCommand:Ifamessageisreceivedthatthereareerrorsinthezonefile,correct
509 them;otherwiserestartasfollows:
510 a. ForRedHatorCentosServer:
511 /etc/init.d/nsd restart
512 b. ForDebianorUbuntuserver:
513 /etc/init.d/nsd4 restart

514 Note: A restart is not needed to reload zonefile. Use reload or reconfig.

515 2.4.2.4 Testing NSD4


516 TheeasiestwaytotesttheNSD4configurationistorunadigfromtheresolverqueryingthe
517 NSDserverforthedomainyoujustdefined,suchas:
518 dig @129.6.45.38 dnslabs.dnsops.gov

519 Theoutputshouldlooksomethinglikethefollowing:
520 ; &lt;&lt;&gt;&gt ; DIG 9.3.6-20.P1.e15_8.2 ;
521 &lt;&lt;&gt;&gt; @129.6.45.38 dnslabs.dnsops.gov
522 ; 1(1 server found)
523 ;; global options: printcmd
524 ;; Got answer:
525 ;; -&gt;&gt;HEADER&lt;

DNS-Based Email Security Practice Guide DRAFT 28


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

526 InthisoutputyoushouldseeintheanswersectionthecorrectassociationbetweenyourDNS
527 nameandIP,andintheAUTHORITYsectionthecorrectassociationbetweenyourNSandthe
528 configuredIP.

529 2.4.2.5 NSD4 Support


530 AlthoughNSD4isopensourcesoftware,supportisavailablefromNLnetLabsviaitssubsidiary
531 OpenNetlabs(http://www.opennetlabs.com).

532 2.5 How to Install and Configure OpenDNSSEC


533 ThelogfileforanactualNCCoEinstallationandconfigurationofOpenDNSSECwithUnbound
534 andNSD4fortheDNS-BasedEmailSecurityprojectisprovidedasAppendixF.Forcryptographic
535 operations,OpenDNSSECusesthePKCS#11interfacesupportedbyhardwaresecuritymodules
536 (HSMs).AsanalternativetorealHSMs,theOpenDNSSECprojectdevelopedSoftHSM,adrop-in
537 replacementthatusestheBotanorOpenSSLcryptographiclibrary.SQLiteorMySQLcanbe
538 usedasdatabaseback-ends.Itisusedonthe.se,.dk,.nl,.ca,and.uktop-leveldomainsand
539 more.OpenDNSSECcanbedownloadedfrom:
540 https://dist.opendnssec.org/source/opendnssec-2.0.1.tar.gz
541 https://dist.opendnssec.org/source/opendnssec-2.0.1.tar.gz.sig
542 ChecksumSHA256:
543 bf874bbb346699a5b539699f90a54e0c15fff0574df7a3c118abb30938b7b346
544 PleasenotethatIPaddresses,domainnames,andmailaddressesare,inmanycases,specificto
545 theNCCoElaboratoryconfigurationandmustnotbeusedinactualimplementations.

546 2.5.1 OpenDNSSEC Installation Basics and System Requirements


547 OpenDNSSEC1willrunonmostLinux,BSDandSolarisoperatingsystems.Thecommunity
548 providesbinarypackagesforseveralplatformstoassistinstallation.ThisPracticeGuide,
549 however,assumesthosepackagesarenotavailable.Ifyouhavefoundanappropriatesystemto
550 runOpenDNSSECon,itistimetoinstallitsdependencies.OpenDNSSECreliesonadatabase
551 backendandcurrentlysupportsMySQLandSQLite.MySQLisrecommendedbecauseSQLite
552 doesn'tscalewellandhassomeknownlockingissues.Furthermore,OpenDNSSECdependson:
553 ldns,version1.6.12andupwiththeexceptionsof1.6.14and1.6.15
554 libxml2,libxml2-dev,libxml2
555 Asindicatedabove,OpenDNSSECgenerallyassumesuseofacryptographicHardwareSecurity
556 Module(HSM)viathePKCS#11interface.AnalternativeisuseofSoftHSM,asoftware-only
557 implementationofanHSM.SoftHSMdependsonBotan(acryptographiclibrary)version1.8.5
558 orgreater,orOpenSSL(forSoftHSM2.0andhigher),andSQLiteversion3.3.9orgreater.Install
559 SoftHSM(https://www.opendnssec.org/2016/03/softhsm-2-1-0/)with:
560 $ tar -xzf softhsm-X.Y.Z.tar.gz

1.https://www.opendnssec.org/.

DNS-Based Email Security Practice Guide DRAFT 29


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

561 $ cd softhsm-X.Y.Z $ ./configure


562 $ make
563 $ sudo make install
564 Bydefault,thebinarywillbeinstalledin/usr/local/bin/andtheconfigurationisexpected
565 tobeat/etc/softhsm.conf.OpenthefileandspecifyaslotforOpenDNSSEC.Forexample:
566 # SoftHSM slots 0:/var/lib/softhsm/slot0.db
567 Thetokendatabasedoesnotexistatthisstage.Itisnecessarytoinitializeitwith:
568 $ softhsm --init-token --slot 0 --label "OpenDNSSEC"
569 Whenprompted,fillinaSO(SecurityOfficer)PINanduserPIN.Rememberit,youwillneedto
570 configureitforOpenDNSSEC.TheSOPINcanbeusedtoreinitializethetoken.TheuserPINis
571 handedouttoOpenDNSSEC.IfyourcompanydoesnothaveaSO,justpickthesamePINfor
572 bothroles.
573 MakesureOpenDNSSEChaspermissiontoaccessthetokendatabase.
574 $ chown opendnssec /var/lib/softhsm/slot0.db
575 $ chgrp opendnssec /var/lib/softhsm/slot0.db

576 2.5.2 OpenDNSSEC Installation


577 WhilethelogfileforanactualinstallationandconfigurationofOpenDNSSECwithUnboundand
578 NSD4fortheDNS-BasedEmailSecurityprojectisprovidedasAppendixF,somemoregeneral
579 informationregardingOpenDNSSECinstallation1follows:
580 RunthesecommandstoinstallOpenDNSSEC:
581 $ tar -xzf opendnssec-X.Y.Z.tar.gz
582 $ cd OpenDNSSEC-X.Y.Z $ ./configure
583 $ make
584 $ make install
585 Bydefault,thebinarieswillbeinstalledin/usr/local/bin/and/usr/local/sbin/.The
586 configurationfilesarelocatedinthe/etc/opendnssec/directory.Theworkingdirectoriesare
587 under/var/opendnssec/.

588 2.5.3 OpenDNSSEC Configuration Requirements


589 Thedefaultconfigurationinstallsdefaultvaluesforentitiesthatjustwantstosigntheirdomains
590 withDNSSEC.TherearefourconfigurationfilesforthebasicOpenDNSSECinstallation:
591 conf.xmlwhichistheoverallconfigurationofthesystem
592 kasp.xmlwhichcontainsthepolicyofsigning
593 zonelist.xmlwhereyoulistallthezonesthatyouaregoingtosign

1.TheNLnetLabsOpenDNSSECteamprovidedmostofthetextinthissection.Thistextisalso

available in an expanded form on OpenDNSSEC Wiki https://wiki.opendnssec.org/dis-
play/DOCS20/OpenDNSSEC.

DNS-Based Email Security Practice Guide DRAFT 30


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

594 addns.xml (perzone,optional)forzonetransfers


595 Fornow,itisnecessarytoeditconf.xmlonlybecauseweneedtoconfigurethecryptographic
596 securitymodulemustbeconfigured(e.g.,anHSMorsoftwaremodulesuchasSoftHSMor
597 SoftHSM2.x).MaketheRepositorypartlooklike:
598 <Repository name="SoftHSM">
599 <Module>/usr/local/lib/libsofthsm.so</Module>
600 <TokenLabel>OpenDNSSEC</TokenLabel>
601 <PIN>XXXX</PIN>
602 <SkipPublicKey/>
603 </Repository>
604 Here,XXXXistheuserPINenteredinsection2.4.1above.
605 OpenDNSSECsKeyandSigningPolicy(KASP)providesstandardvaluesforsigninganyzone.
606 However,ifanorganizationchoosestochangeanyvalue,itispossibletoaddanewpolicy,or
607 changevaluesinanexistingpolicy.Forexample,ifazoneusestheYYYYMMDDXXformatfor
608 SOA SERIALvalues,changetheSerialparameterinkasp.xmlfromunixtimetodatecounter:
609 <Zone>
610 <PropagationDelay>PT9999S</PropagationDelay>
611 <SOA>
612 <TTL>PT3600S</TTL>
613 <Minimum>PT3600S</Minimum>
614 <Serial>datecounter</Serial>
615 </SOA>
616 </Zone>
617 ForfulldescriptionsaboutalltheKASPparameters,seetheOpenDNSSECWiki1.

618 2.5.4 Running OpenDNSSEC


619 WhenstartingOpenDNSSECforthefirsttime,itisfirstnecessarytosetupthedatabase.There
620 isacontrolscriptthatstartsuptwodaemons:ods-enforcerdthattakescareofthekey
621 management,andods-signerdthatistheactualsigner.
622 Run:
623 $ ods-enforcer-db-setup
624 *WARNING* This will erase all data in the database; are you sure? [y/n]
625 y
626 $ ods-control start
627 Atthispoint,OpenDNSSECisrunning.Logsaregoingtosyslog.Thesetuphasimportedthetwo
628 defaultKeyAndSigningPolicies(KASP),defaultandlab.However,nozonesareimportedyet.

1.OpenDNSSECDocumentation:https://wiki.opendnssec.org/display/DOCS20/kasp.xml.

DNS-Based Email Security Practice Guide DRAFT 31


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

629 2.5.5 Adding Zones


630 Untilthezonelistzonelist.xmlisedited,OpenDNSSECstartswithnozonestosign.Itis
631 necessarytoaddzones(andremovezonesasnecessary).Onewaytoaddazoneistoenterthe
632 followingcommand:
633 $ ods-enforcer zone add -z example.com
634 Thisaddsthezoneexample.comtoOpenDNSSECwiththedefaultKASP.Alsobydefault,the
635 signingisfilebased.Notethattheenforcerdoesn'treadthisfilewithoutbeingtoldexplicitlyto
636 doso.Also,thefilewillnotbewrittenwhenaddingnewzonesviacommandline.
637 Thesignerexpectstheunsignedfiletobeat/var/opendnssec/unsigned/example.com
638 andputsthesignedfileat/var/opendnssec/signed/example.com.Differentpathscanbe
639 usedwith-i(input)and-o(output).Youcanuseadifferentpolicywith-p(policy).
640 IfauseroradministratorwantstouseDNSzonetransfersforinputandoutput,thetypeof
641 adaptercanbesettoDNS,-jforinputand-qforoutput.Itisnecessarytosettheinputand
642 outputfilestothezonetransferconfigurationfileaddns.xml,likethis:
643 $ ods-ksmutil zone add -z example.com -j DNS -q DNS \
644 -i /etc/opendnssec/addns.xml -o /etc/opendnssec/addns.xml
645 Instructionsonhowtoeditaddns.xmlforzonetransfersisdescribedinsection2.5.5.1below.
646 Thesignedzoneisthenwritteninthe/var/opendnssec/signed/directory.Itisnecessary
647 tonotifyyournameserverofthenewzonefileinorderforthezonetoalsobecomevisiblein
648 theDNS.Itispossibletoconfigureanotifycommandinconf.xmltoautomaticallynotifythe
649 nameserverofnewzones.Forexample:
650 <Configuration>
651 ...
652 <Signer>
653 ...
654 <NotifyCommand>nameserver_control_program reload
655 %zone</NotifyCommand>
656 </Signer>
657 </Configuration>
658 Here,%zonewillbereplacedwiththenameofthezonethathasbeenupdated,and%zonefile
659 (notusedinexample)willbereplacedwiththenameofthesignedzonefile.

660 2.5.5.1 OpenDNSSEC as a Bump-in-the-Wire


661 IfazonehasbeenaddedwithDNSadaptersratherthanworkingonfiles,insteadofpointing
662 theinputandoutputtothefilenamesoftheunsignedandsignedzones,itisnecessarytoputin
663 thezonetransferconfigurationfileaddns.xml.Here,primarynameserveraddresses,portsand
664 TSIGkeys(Inbound),andportsandTSIGkeysforthesecondarynameservers(Outbound)are
665 setup.Replacetheexamplevaluesinaddns.xml.sampleinstalledin/etc/opendnssec/with
666 thedesiredserversandkeysandrenameittoaddns.xml.Alsoconf.xmlneedsasocketthat
667 listenstoDNStraffic:
668 <Configuration>
669 ...

DNS-Based Email Security Practice Guide DRAFT 32


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

670 <Signer>
671 ...
672 <Listener>
673 <Interface><Address>127.0.0.1</Address><Port>53</Port></Interface>
674 <Interface><Address>::1</Address><Port>53</Port></Interface>
675 <Listener>
676 </Signer>
677 </Configuration>
678 Theabovevaluesarealsothedefaults.OpenDNSSECcannowsignincomingzonetransfers(full
679 andincremental)andalsoreplytoSOA,AXFRandIXFRrequests.

680 2.5.5.2 Activating Key Signing Keys (KSK)


681 Atthisstage,anattempttolistOpenDNSSECkeyswillrevealthatthekeysigningkey(KSK)isnot
682 yetactive:
683 $ ods-enforcer key list -a
684 Zone: Keytype: State: Date of next transition:
685 example.com. KSK publish 2016-09-01 00:00:01 example.com. ZSK active
686 2016-08-31 10:00:01
687 ThisisbecausetheDSmuststillbesubmittedtotheparent.TheDSisarecordthatisderived
688 fromtheKSKandispublishedintheparentzone.Thisisusedtobuildasecurechainoftrust
689 fromtherootzonetotheuserszone.Intheexampleabove,OpenDNSSECexpectsthisto
690 happenatonesecondpastmidnightonthefirstofSeptember2016.Thisis14hoursafterinitial
691 signing.Thisisbecausethedefaultpolicyhasaveryconservativepropagationdelayforthe
692 nameservers:12hours.Inthisexample,ittakesanadditionalhourfortheTTLandonemore
693 forthepublishsafetyparameter-totaling14hoursEnduringthelongpropagationdelayis
694 necessarybecause,inordertomakesureazoneremainsvalid,itisnecessarytorespecta
695 publishsafetydurationandtheTTL(inthiscasederivedfromtheSOA MINIMUM).If
696 OpenDNSSECisready,thedateofnexttransitionbedisplayedaswaiting for ds-seen.TheDS
697 canthenbesubmittedtotheparent.Howthatisaccomplisheddependsonyourorganization's
698 registrar.Usuallythiscanbedoneviae-mailorthroughawebinterface.RetrievetheDNSKEYor
699 DSwith:
700 $ ods-enforcer key export
701 ;ready KSK DNSKEY record: example.com. 3600 IN DNSKEY 257 3 8 Aw...
702 $ ods-enforcer key export -d
703 ;ready KSK DS record (SHA1): example.com.. 3600 IN DS 42112 8 1 8aea...
704 ;ready KSK DS record (SHA256): example.com. 3600 IN DS 42112 8 2
705 a674...
706 IftheDSshowsupintheparentzoneatallparentnameservers,itissafetorunthekey
707 ds-seencommand.Thiscommandrequiresthekeytagofthekeyinquestion.Youcanseefrom
708 theDNSKEYandDSrecordsthisis42112inthisexample:
709 $ ods-enforcer key ds-seen -z example.com -x 42112
710 TheKSKisnowalsoactive,andthechain-of-trustissetup.

DNS-Based Email Security Practice Guide DRAFT 33


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

711 2.6 Unbound


712 ThelogfileforanactualNCCoEinstallationandconfigurationofUnboundwithNSD4and
713 OpenDNSSECfortheDNS-BasedEmailSecurityprojectisprovidedasAppendixF.Thelatest
714 versionofunbound(currently1.5.10)canalwaysbedownloadedfrom
715 http://www.unbound.net/downloads/unbound-latest.tar.gz.1Unbounddocumentationcanbe
716 foundathttps://unbound.net/documentation/index.html.Somegeneralinstallationand
717 configurationinformationforUnboundisprovidedinthefollowingsubsections.Pleasenote
718 thatIPaddresses,domainnames,andmailaddressesare,inmanycases,specifictotheNCCoE
719 laboratoryconfigurationandmustnotbeusedinactualimplementations.

720 2.6.1 Unbound Installation Basics and System Requirements


721 IfyourdistributionpackagemanagerincludesapackageforUnboundinstallthepackagewith
722 thepackagemanager.Ifnot,inordertocompilethesoftwareitisnecessarytohaveopenssl,
723 anditsincludefiles(fromapackageoftencalledopenssl-devel).Inopenssl,run./configure
724 [options]; make;andmake install.Forcasesinwhichthelibldnslibraryisnotinstalled,a
725 versionisincludedwiththeUnboundsourcetarballandisautomaticallyused.Unboundalways
726 usessldns(theincludedldns).Withrespecttooptionsforconfigure,thedefaultconfig
727 locationsforvariousfilesanddirectoriescanbecustomized,aswellastheinstalllocationfor
728 theprogramwith--prefix=/usr/local.Youcanspecify--with-libevent=diror
729 --with-ssl=dirtolinkwiththelibraryatthatlocation.Ingeneral,nooptionsareneededfor
730 ./configure.

731 OnsomeBSDsystemsitisnecessarytousegmakeinsteadofmake.
732 Itispossibletoinstallwithmake installandtouninstallwithmake uninstall.Theuninstall
733 doesnotremovetheconfigfile.Inthecontrib directoryintheunboundsourcearesamplerc.d
734 scriptsforunbound(forBSDandLinuxtypesystems).

735 2.6.2 Unbound Setup and Installation


736 Theconfigfileiscopiedinto/usr/local/etc/unbound/unbound.confbutsome
737 distributionsmayputitin/etc/unbound/unbound.confor/etc/unbound.conf.The
738 configfileisfullyannotated,youcangothroughitandselecttheoptionsyoulike.Oryoucan
739 usethebelow,aquicksetofcommonoptionstoservethelocalsubnet.Acommonsetupfor
740 DNSserviceforanIPv4subnetandIPv6localhostisbelow.YoucanchangetheIPv4subnetto
741 matchthesubnetthatyouuse,andaddyourIPv6subnetifyouhaveone.
742 # unbound.conf for a local subnet.
743 server:
744 interface: 0.0.0.0
745 interface: ::0

1.Source: unbound-1.5.9.tar.gz; SHA1 checksum: 4882c52aac0ab-


cd72a86ac5d06e9cd39576620ce; SHA256 checksum:
01328cfac99ab5b8c47115151896a244979e442e284eb962c0ea84b7782b6990; PGP signature:
unbound-1.5.9.tar.gz.asc;License:BSD;Doc:man-page.

DNS-Based Email Security Practice Guide DRAFT 34


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

746 access-control: 192.168.0.0/16 allow


747 access-control: ::1 allow
748 verbosity: 1
749 Bydefaultthesoftwarecomeswithchrootenabled.Thisprovidesanextralayerofdefense
750 againstremoteexploits.Enterfilepathsasfullpathnamesstartingattherootofthefilesystem
751 ('/').Ifchrootgivesyoutrouble,youcandisableitwithchroot: ""intheconfig.Alsothe
752 serverassumestheusernameunboundtodropprivileges.Youcanaddthisuserwithyour
753 favoriteaccountmanagementtool(useradd(8)),ordisablethefeature1withusername: ""in
754 theconfig.
755 Starttheserverusingthescript(ifyouorthepackagemanagerinstalledone)as
756 /etc/rc.d/init.d/unbound start.orunbound -c <config>asroot.

757 Itispossibletosetupremotecontrolusingunbound-control.Firstrun
758 unbound-control-setuptogeneratethenecessaryTLSkeyfiles(theyareputinthedefault
759 installdirectory).Ifyouuseausernameofunboundtorunthedaemonfromuse sudo -u
760 unbound unbound-control-setuptogeneratethekeys,sothattheserverisallowedtoread
761 thekeys.Thenaddthefollowingattheendoftheconfigfile:
762 # enable remote-control
763 remote-control:
764 control-enable: yes
765 Youcannowuseunbound-controltosendcommandstothedaemon.Itneedstoreadthekey
766 files,soyoumayneedtosudo unbound-control.Onlyconnectionsfromlocalhostareallowed
767 bydefault

768 2.6.3 Unbound Configuration for DNSSEC


769 DNSSECisamechanismtoprotectDNSdata.Itusesdigitalsignatures.TouseDNSSECwith
770 Unbound,thepublickeysfordigitalsignaturemustbeconfigured.Notethatspecific
771 distributions,operatingsystems,ordevicevendorsmayhavealreadyprovidedtheanchor,
772 securingitwithitsownvendor-specificupdatemechanism.Inthatcase,themechanisms
773 providedfromthosesourcesshouldbeused.

774 2.6.3.1 Trust Anchor


775 ThefirststepinconfiguringUnboundforDNSSECistoobtainaninitialtrustanchor.2The
776 unbound-anchortoolprovidesaninitialanchorfrombuilt-invalues,butforrealtrustthis
777 shouldbecheckedthoroughly.Therootkeyisstoredinafile,
778 /usr/local/etc/unbound/root.key.Unboundmustbeabletoreadandwriteit,tokeep
779 ituptodatewiththelatestkey(s).ItmustthereforeresidewithinthechrootofUnbound(if
780 thatisused).Accessrightsareworld-readable,userUnboundwriteonly.Usesudo -u unbound
781 tostartunbound-anchor sothatthefileownerissettotheunbounduser(sameusernameas
782 daemonuses).Itcanoptionallybeputsomewhereelse,accessibletotheunbounddaemon,
783 suchas/var/unboundor/etc.Youneedtopassthisvaluetounbound-anchor(option-a

1.Donotrunasroot.
2.Unbound:HowtoenableDNSSEC,W.C.A.Wijngaards,NLnetLabs,April2011.

DNS-Based Email Security Practice Guide DRAFT 35


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

784 file)andtounbound(auto-trust-anchor-file:fileinunbound.conf).Theunbound-anchor
785 toolcreatesthisfilefortheadministratorifitdoesnotexist.Buttheadministratormustcheck
786 thisfilesothatitcanbetrusted.Theunbound-anchortoolalsohasabuilt-incertificate(from
787 theICANNCertificateAuthority)thatitwillusetoupdatetherootkeyifitbecomesoutofdate,
788 thisshouldbecheckedtoo(-loptiontoshowit),orprovidesomeothercertificatethat
789 unbound-anchoristouse.
790 Therearetrustedcommunityrepresentativesthathaveswornandsignedattestations,and
791 theremaybepublications(i.e.inprintedform).PleasenoticethatNLnetLabs'unbound-anchor
792 toolprovidesaninitialvalueforconvenience,systemsadministratorsmustperformthe
793 specifiedcheckstoobtaintrust.ThetrustanchorcanbedownloadedviahttpsfromIANA:
794 root-anchors.xml(clicklinkandthencheckthelockiconandtheurlbarandthehashdisplayed
795 againstthehashyoucanputasinitialvalueintotheroot.keyfile,seebelowforanexampleof
796 thesyntaxofhowtoinputtheinitialvalue).
797 Hereisthe2010-2011trustanchorfortherootzone.Thisisthesyntaxthatyoucanuseto
798 provideaninitialvaluefortheroot.keyfile:
799 . IN DS 19036 8 2
800 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

801 2.6.3.2 Update Mechanism Setup


802 Settheunbound-anchortooltorunatsystemstartup,itispartoftheUnboundpackage.A
803 goodwayistorunitfromtheinitscripts,withsudo -u unboundsothatthefilepermissions
804 workout.
805 Beforeunbound-anchorisruninsidetheinitscripts,youmustrunNTP(insecuremode),so
806 thatthetimeanddatehavebeensetproperly.UnboundusesRFC5011updatestokeepthe
807 anchorupdatedifitischangedwhilethecomputerisinoperation,buttheunbound-anchor
808 toolisusedifitischangedwhilethecomputerisnotinoperation.
809 Intheunbound.confconfigfile,includetherootanchorfilewiththeautomaticupdatedanchor
810 statement,likethis:
811 server:
812 # ... other stuff
813 # root key file, automatically updated
814 auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
815 Afteryouchangetheconfig,restartunbound.Unboundwillthenoverwritethekeyfilewith
816 statusinformation(suchasthelasttimethekeywasseen).

817 2.6.3.3 Testing Unbound Configurations for DNSSEC


818 Enteringdig com. SOA +dnssecshouldresultindisplayoftheADflagthere.Ifthisis
819 unsuccessful,theUnboundoption val-log-level: 2shouldlogexplanationsregardingwhy
820 theDNSSECvalidationfails(onelineperfailedquery).Also,http://test.dnssec-or-not.org/(fun
821 test)orhttps://internet.nl/(sobertest)andhttp://www.kaminskybug.se/(lookforahappybug
822 icon)areusefultesttools.

DNS-Based Email Security Practice Guide DRAFT 36


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

823 2.6.4 Unbound Support


824 Althoughitisopensourcesoftware,supportforUnboundisavailablefromanumberof
825 sources,includingNLnetLabs.

826 2.7 How to Install and Configure a DNS Signer Platform


827 DNSSignerisacommercialproduct,theinstallationandconfigurationinstructionscanbe
828 obtainedfromthecompanywebsite,http://www.secure64.com/.

829 2.7.1 DNS Signer Installation Basics and System Requirements


830 Secure64DNSSignerrunsonHPIntegrityserverswiththefollowingminimumconfiguration:
831 1dualcoreItaniummicroprocessor
832 4GBRAM
833 36GBdiskdrive
834 DVDROMdrive
835 DNSSignerisacommercialproduct.Informationregardingobtainingtheproductcanbefound
836 athttp://www.secure64.com/contact.

837 2.7.2 DNS Signer Installation and Configuration


838 DNSSignercanbeconfiguredtoworkwithanauthoritativeDNSresolver,(e.g.,DNSAuthority)
839 oracaching/recursiveresolver(e.g.,DNSCache).TheprocessfollowedforinstallationofDNS
840 SignerattheNCCoEisincludedinAppendixH.

841 2.8 How to Install and Configure a DNS Authority


842 Platform
843 DNSAuthorityisacommercialproduct,theinstallationandconfigurationinstructionscanbe
844 obtainedfromthecompanywebsite,http://www.secure64.com/.Informationregarding
845 obtainingtheproductcanbefoundathttp://www.secure64.com/contact.DNSAuthoritycan
846 beconfiguredtoworkwithacaching/recursiveresolver(e.g.,DNSCache)andaDNSSigner.The
847 processfollowedforinstallationofDNSAuthorityattheNCCoEisincludedinAppendixH.

848 2.9 How to Install and Configure DNS Cache


849 DNSCacheisacommercialproduct,installationandconfigurationinstructionscanbeobtained
850 fromthecompanywebsite,http://www.secure64.com/.Informationregardingobtainingthe
851 productcanbefoundathttp://www.secure64.com/contact.

DNS-Based Email Security Practice Guide DRAFT 37


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

852 2.10 How to Install and Configure a Dovecot/Postfix Mail


853 Transfer Agent

854 2.10.1 Dovecot Installation Basics and System Requirements


855 DovecotcanbedownloadedfromsourcesidentifiedattheDovecotSecureIMAPServersite
856 (http://www.dovecot.org/download.html).

857 2.10.1.1 Compiling Dovecot from Source Code


858 TocompileDovecotfromsourcecodeprovidethefollowingcommands:
859 ./configure
860 make
861 sudo make install
862 ThatinstallsDovecotunderthe/usr/localdirectory.Theconfigurationfileisin
863 /usr/local/etc/dovecot.conf.Logginggoestosyslog'smailfacilitybydefault,which
864 typicallygoesto/var/log/mail.logorsomethingsimilar.Ifyouareinahurry,youcanthenjump
865 toQuickConfiguration.Ifyouhaveinstalledsomelibrariesintolocationswhichrequirespecial
866 includeorlibrarypaths,youcanpassthemintheCPPFLAGSandLDFLAGSenvironment
867 variables.Forexample:
868 CPPFLAGS="-I/opt/openssl/include" LDFLAGS="-L/opt/openssl/lib"
869 ./configure
870 ItisnecessarytocreatetwousersforDovecot'sinternaluse:
871 dovenull:Usedbyuntrustedimap-loginandpop3-loginprocesses(default_login_user
872 setting).
873 dovecot:UsedbyslightlymoretrustedDovecotprocesses(default_internal_usersetting).
874 Eachofthemshouldalsohaveitsowndovenullanddovecotgroups.See
875 http://wiki2.dovecot.org/UserIdsformoreinformation.

876 2.10.1.2 Compiling Dovecot from Git


877 DovecotisavailablefromGit,forexamplewith:
878 git clone https://github.com/dovecot/core.git dovecot
879 TocompileDovecotfromGit,itisfirstnecessarytorun./autogen.shtogeneratethe
880 configurescriptandsomeotherfiles.Thisrequiresthatthefollowingsoftware/packagesbe
881 installed:
882 autoconf
883 automake
884 libtool
885 pkg-config
886 gettext

DNS-Based Email Security Practice Guide DRAFT 38


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

887 GNUmake
888 Itisadvisabletoadd--enable-maintainer-modetotheconfigurescript:
889 ./autogen.sh
890 ./configure --enable-maintainer-mode
891 make
892 sudo make install
893 Forlaterupdates,thecommandsare:
894 git pull
895 make
896 sudo make install

897 2.10.1.3 Compiling Dovecot with rpmbuild (Mandriva, RedHat, etc.)


898 Fetchthesourcerpmfromftp://ftp.surfnet.nl/oranyothermirror.Currently,
899 dovecot-10.rc26.src.rpmcanbefoundinthecookersubtree.Ifthecurrentreleaseisnewer,
900 unpackthesourcerpmwithrpm -ivh dovecot-10.rc26.src.rpmtoabuildenvironment
901 (/usr/src/rpm...)CopythenewertarballfromthedovecotsitetotheSOURCESdirectory
902 ofthebuildenvironment.Changethedovecot.specfileintheSPECSdirectorytoreflectthe
903 newreleaseandthenewnameofthetarball.Themaintainerworkswithabz2 tarball;a tar.gz
904 tarballmakesnodifference.Issuearpmbuild -ba dovecot.spec.Theresultingrpmwillbe
905 placedinRPMS/i586.Installwithrpmorurpmi:
906 rpm -ivh dovecot-1.0.rc26.src.rpm
907 cd /usr/src/rpm
908 mv ~/downloads/dovecot-1.0.rc28.tar.gz ./SOURCES
909 cd SPECS
910 vi dovecot.spec
911 ...edit release and tarball name. Change default options if needed...
912 rpmbuild -ba dovecot.spec
913 cd ../RPMS/i586
914 urpmi ./dovecot-1.0.rc28-1mdv2007.0.i586.rpm
915 Duringthisprocessmissingprerequisitesmaybedetected.Installthemandrerunthebuild
916 process.Thespecfilealsoneedupdatingforthenewadd-ons(idxviewandlogview).

917 2.10.1.4 SSL/TLS Support


918 DovecotwasinitiallybuilttosupportbothOpenSSLandGNUTLS,butOpenSSLiscurrentlyused
919 bydefault,anditshouldbeautomaticallydetected.Ifitisnot,someheaderfilesorlibrariesare
920 missing,ortheyareinanon-standardpath.Theopenssl-devorasimilarpackageneedstobe
921 installed,andifitisnotinthestandardlocation,setCPPFLAGSandLDFLAGSasshownabove.
922 BydefaulttheSSLcertificateisreadfrom/etc/ssl/certs/dovecot.pem,andtheprivate
923 keyfrom/etc/ssl/private/dovecot.pem.The/etc/ssldirectorycanbechangedusing
924 the--with-ssldir=DIRconfigureoption.Bothcanofcoursebeoverriddenfromthe
925 configurationfile.

DNS-Based Email Security Practice Guide DRAFT 39


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

926 ForLinuxinstallations,notethatcurrentinotifyisintheLinuxkernelsinceversion2.6.13andit
927 ispreferredoverdnotify.Ifyourdistributiondoesnothavetherequiredinotifyheaderfile,it
928 canbeobtainedfromtheinotify maintainer(thefollowingexamplerequirescURL):
929 mkdir -p /usr/local/include/sys
930 cd /usr/local/include/sys
931 curl
932 ftp://ftp.kernel.org/pub/linux/kernel/people/rml/inotify/headers/inoti
933 fy.h -O
934 curl
935 ftp://ftp.kernel.org/pub/linux/kernel/people/rml/inotify/headers/inoti
936 fy-syscalls.h >> inotify.h
937 /usr/local/includeisn'tinstandardincludelookuppath,sothatneedstobespecifiedto
938 configure:
939 CPPFLAGS=-I/usr/local/include ./configure --with-notify=inotify

940 2.10.1.5 Dovecot Configuration Options


941 --help
942 givesafulllistofavailableoptions
943 --help=short
944 justliststheoptionsaddedbytheparticularpackage(=Dovecot)
945 Optionsareusuallylistedas--with-somethingor--enable-something.Ifyouwanttodisable
946 them,doitas--without-somethingor--disable-something.Therearemanydefault
947 optionsthatcomefromautoconf,automakeorlibtool.ThelistofoptionsthatDovecotadds
948 follows:
949 --enable-devel-checks
950 Enablessomeextrasanitychecks.Thisismainlyusefulfordevelopers.Itdoesquitealotof
951 unnecessaryworkbutshouldcatchsomeprogrammingmistakesmorequickly.
952 --enable-asserts
953 Enableassertionchecks,enabledbydefault.DisablingthemmayslightlysavesomeCPU,
954 butiftherearebugstheycancausemoreproblemssincetheyarenotdetectedasearly.
955 --without-shared-libs
956 LinkDovecotbinarieswithstaticlibrariesinsteadofdynamiclibraries.
957 --disable-largefile
958 Specifiesifweuse32bitor64bitfileoffsetsin32bitCPUs.64bitisthedefaultifthesystem
959 supportsit(LinuxandSolarisdo).Droppingthisto32bitmaysavesomememory,butit
960 preventsaccessinganyfilelargerthan2GB.
961 --with-mem-align=BYTES
962 Specifiesmemoryalignmentusedformemoryallocations.Itisneededwithmanynon-x86
963 systemsanditshouldspeedupx86systemstoo.Defaultis8,tomakesure64bitmemory
964 accessingworks.
965 --with-ioloop=IOLOOP

DNS-Based Email Security Practice Guide DRAFT 40


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

966 SpecifieswhatI/Oloopmethodtouse.Possibilitiesareselect,poll,epollandkqueue.The
967 defaultistousethebestmethodavailableonyoursystem.
968 --with-notify=NOTIFY
969 Specifieswhatfilesystemnotificationmethodtouse.Possibilitiesarednotify,inotify(both
970 onLinux),kqueue(FreeBSD)andnone.Thedefaultistousethebestmethodavailableon
971 yoursystem.SeeNotifymethodaboveformoreinformation.
972 --with-storages=FORMATS
973 Specifieswhatmailboxformatstosupport.Note:Independentofthisoption,theformats
974 rawandsharedwillbealwaysbuilt.
975 --with-solr
976 BuildwithSolrfulltextsearchsupport
977 --with-zlib
978 Buildwithzlibcompressionsupport(defaultifdetected)
979 --with-bzlib
980 Buildwithbzip2compressionsupport(defaultifdetected)

981 SQL Driver Options


982 SQLdriversaretypicallyusedonlyforauthentication,buttheymaybeusedasalib-dict
983 backendtoo,whichcanbeusedbypluginsfordifferentpurposes.
984 --with-sql-drivers
985 BuildwithspecifiedSQLdrivers.Defaultstoallthatwerefoundwithautodetection.
986 --with-pgsql
987 BuildwithPostgreSQLsupport(requirespgsql-devel,libpq-devorsimilarpackage)
988 --with-mysql
989 BuildwithMySQLsupport(requiresmysql-devel,libmysqlclient15-devorsimilarpackage)
990 --with-sqlite
991 BuildwithSQLite3driversupport(requiressqlite-devel,libsqlite3-devorsimilarpackage)

992 Authentication Backend Options


993 Thebasicbackendsarebuiltifthesystemisdetectedtosupportthem:
994 --with-shadow
995 Buildwithshadowpasswordsupport
996 --with-pam
997 BuildwithPAMsupport
998 --with-nss
999 BuildwithNSSsupport
1000 --with-sia
1001 BuildwithTru64SIAsupport
1002 --with-bsdauth
1003 BuildwithBSDauthenticationsupport(ifsupportedbyyourOS)

DNS-Based Email Security Practice Guide DRAFT 41


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

1004 Somebackendsrequireextralibrariesandarenotnecessarilywanted,sotheyarebuiltonlyif
1005 specificallyenabled:
1006 --with-sql
1007 BuildwithgenericSQLsupport(driversareenabledseparately)
1008 --with-ldap
1009 BuildwithLDAPsupport(requiresopenldap-devel,libldap2-devorsimilarpackage)
1010 --with-gssapi
1011 BuildwithGSSAPIauthenticationsupport(requireskrb5-devel,libkrb5-devorsimilar
1012 package)
1013 --with-vpopmail
1014 Buildwithvpopmailsupport(requiresvpopmailsourcesoradevelopmentpackage)
1015 It'salsopossibletobuildtheseaspluginsbygivinge.g.--with-sql=plugin.

1016 2.10.1.6 Dovecot Support


1017 AlthoughDovecotisopensourcesoftware,supportisavailablefromdovecot.organd
1018 commercialsources.Seehttp://www.dovecot.org/support.html.

1019 2.10.2 Postfix Installation and Configuration


1020 PostfixwasreleasedundertheIBMPublicLicense,andsourcecodecanbedownloadedfrom
1021 http://cdn.postfix.johnriley.me/mirrors/postfix-release/index.html.AllPostfixsourcecodeis
1022 signedwithWietse'sPGPkey.1InstructionsforinstallingPostfixfromsourcecodecanbefound
1023 athttp://www.postfix.org/INSTALL.html.Postfixmanualpagescanbefoundat
1024 http://www.postfix.org/postfix-manuals.html.

1025 2.10.2.1 Installation and System Requirements


1026 Ifyouareusingapre-compiledversionofPostfix,youshouldstartwith
1027 BASIC_CONFIGURATION_READMEandthegeneraldocumentationreferencedbyit.INSTALLis
1028 onlyabootstrapdocumenttogetPostfixupandrunningfromscratchwiththeminimalnumber
1029 ofsteps;itisnotconsideredpartofthegeneraldocumentation.TheINSTALLdocument
1030 describeshowtobuild,installandconfigureaPostfixsystemsothatitcandooneofthe
1031 following:
1032 Sendmailonly,withoutchanginganexistingSendmailinstallation.
1033 Sendandreceivemailviaavirtualhostinterface,stillwithoutanychangetoanexisting
1034 Sendmailinstallation.
1035 RunPostfixinsteadofSendmail.

1.Seeftp://ftp.porcupine.org/mirrors/project-history/postfix/foramoreextensivearchiveof
tarballs.

DNS-Based Email Security Practice Guide DRAFT 42


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

1036 AccordingtoINSTALL,PostfixdevelopmentisconductedonFreeBSDandMacOSX,withregular
1037 testsonLinux(Fedora,Ubuntu)andSolaris.Supportforothersystemsreliesonfeedbackfrom
1038 theirusers,andmaynotalwaysbeup-to-date.OpenBSDispartiallysupported.Thelibcresolver
1039 doesnotimplementthedocumented"internalresolveroptionswhichare[...]setbychanging
1040 fieldsinthe_res structure"(documentedintheOpenBSD5.6resolver(3)manpage).Thisresults
1041 intoomanyDNSqueries,andfalsepositivesforqueriesthatshouldfail.

1042 2.10.2.2 Compiler Specifics


1043 IfyouneedtobuildPostfixformultiplearchitecturesfromasinglesource-codetree,usethe
1044 lndircommandtobuildashadowtreewithsymboliclinkstothesourcefiles.Ifatanytimein
1045 thebuildprocessyougetmessageslike:make: don't know how to ... youshouldbe
1046 abletorecoverbyrunningthefollowingcommandfromthePostfixtop-leveldirectory:
1047 $ make -f Makefile.init makefiles
1048 IfyoucopiedthePostfixsourcecodeafterbuildingitonanothermachine,itisagoodideatocd
1049 intothetop-leveldirectoryandfirstdothis:
1050 $ make tidy
1051 Thiswillgetridofanysystemdependenciesleftoverfromcompilingthesoftwareelsewhere.
1052 TobuildwithGCC,orwiththenativecompilerifpeopletoldmethatisbetterforyoursystem,
1053 justcdintothetop-levelPostfixdirectoryofthesourcetreeandtype:
1054 $ make
1055 Tobuildwithanon-defaultcompiler,youneedtospecifythenameofthecompiler,for
1056 example:
1057 $ make makefiles CC=/opt/SUNWspro/bin/cc (Solaris)
1058 $ make
1059 $ make makefiles CC="/opt/ansic/bin/cc -Ae (HP-UX)
1060 $ make
1061 $ make makefiles CC="purify cc"
1062 $ make
1063 Insomecases,optimizationwillbeturnedoffautomatically.

1064 2.10.2.3 Building with Position-Independent Executables


1065 OnsomesystemsPostfixcanbebuiltwithPosition-IndependentExecutables.PIEisusedbythe
1066 ASLRexploitmitigationtechnique(ASLR=Address-SpaceLayoutRandomization).
1067 $ make makefiles pie=yes ...other arguments...
1068 (Specifymake makefiles pie=notoexplicitlydisablePostfixposition-independentexecutable
1069 support).PostfixPIEsupportappearstoworkonFedoraCore20,Ubuntu14.04,FreeBSD9and
1070 10,andNetBSD6(allwiththedefaultsystemcompilers).Whetherthepie=yesabovehasany
1071 effectdependsonthecompiler.SomecompilersalwaysproducePIEexecutables,andsome
1072 mayevencomplainthatthePostfixbuildoptionisredundant.

DNS-Based Email Security Practice Guide DRAFT 43


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

1073 2.10.2.4 Dynamically Linked Libraries


1074 Postfixdynamically-linkedlibraryanddatabasepluginsupportexistsforrecentversionsof
1075 Linux,FreeBSDandMacOSX.Notethatdynamically-linkedlibrarybuildsmaybecomethe
1076 defaultatsomepointinthefuture.

1077 2.10.2.5 Default Settings and Optional Features


1078 Bydefault,Postfixbuildsasamailsystemwithrelativelyfewbellsandwhistles.Supportfor
1079 third-partydatabasesetc.mustbeconfiguredwhenPostfixiscompiled.Thefollowing
1080 documentsdescribehowtobuildPostfixwithsupportforoptionalfeatures:
1081
Table 2.5 Postfix Default Settings and Optional Features

Optional Feature Document Availability

BerkeleyDBdatabase DB_README Postfix1.0

LMDBdatabase LMDB_README Postfix2.11

LDAPdatabase LDAP_README Postfix1.0

MySQLdatabase MYSQL_README Postfix1.0

Perlcompatibleregularexpression PCRE_README Postfix1.0

PostgreSQLdatabase PGSQL_README Postfix2.0

SASLauthentication SASL_README Postfix1.0

SQLitedatabase SQLITE_README Postfix2.8

STARTTLSsessionencryption TLS_README Postfix2.2

1082 Note: IP version 6 support is compiled into Postfix on operating systems that have IPv6 support.
1083 See the IPV6_README file for details.

1084 2.10.2.6 Installing After Compiling


1085 1. SaveexistingSendmailbinaries
1086 SomesystemsimplementamailswitchmechanismwheredifferentMTAs(Postfix,
1087 Sendmail,etc.)canbeinstalledatthesametime,whileonlyoneofthemisactuallybeing
1088 used.ExamplesofsuchswitchingmechanismsaretheFreeBSDmailwrapper(8)ortheLinux
1089 mailswitch.InthiscaseyoushouldtrytofliptheswitchtoPostfixbeforeinstalling
1090 Postfix.Ifyoursystemhasnomailswitchmechanism,executethefollowingcommands
1091 (yoursendmail,newaliasesandmailqprogramsmaybeinadifferentplace):
1092 ?# mv /usr/sbin/sendmail /usr/sbin/sendmail.OFF
1093 # mv /usr/bin/newaliases /usr/bin/newaliases.OFF
1094 # mv /usr/bin/mailq /usr/bin/mailq.OFF
1095 # chmod 755 /usr/sbin/sendmail.OFF/usr/bin/newaliases.OFF\
1096 /usr/bin/mailq.OFF
1097 2. Createaccountandgroups

DNS-Based Email Security Practice Guide DRAFT 44


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

1098 BeforeyouinstallPostfixforthefirsttimeyouneedtocreateanaccountandagroup:
1099 a. Createauseraccountpostfixwithauseridandgroupidthatarenotusedbyanyother
1100 useraccount.Preferably,thisisanaccountthatno-onecanloginto.Theaccountdoes
1101 notneedanexecutableloginshell,andneedsnoexistinghomedirectory.Sample
1102 passwordandgroupfileentriesfollow:
1103 /etc/passwd:
1104 postfix:*:12345:12345:postfix:/no/where:/no/shell
1105 /etc/group:
1106 postfix:*:12345:
1107 Note:thereshouldbenowhitespacebeforepostfix:.
1108 b. Createagrouppostdropwithagroupidthatisnotusedbyanyotheruseraccount.Not
1109 evenbythepostfixuseraccount.Anexampleofagroupfileentryfollows:
1110 /etc/group:
1111 postdrop:*:54321:
1112 Note:thereshouldbenowhitespacebeforepostdrop:.
1113 3. InstallPostfix
1114 ToinstallorupgradePostfixfromcompiledsourcecode,runoneofthefollowing
1115 commandsasthesuper-user:
1116 # make install (interactive version, first time install)
1117 # make upgrade (non-interactive version, for upgrades)
1118 a. Theinteractiveversion(make install)asksforpathnamesforPostfixdataand
1119 programfiles,andstoresyourpreferencesinthemain.cffile.Ifyoudon'twantPostfix
1120 tooverwritenon-Postfixsendmail,mailqandnewaliasesfiles,specifypathnamesthat
1121 endin.postfix.
1122 b. Thenon-interactiveversion(make upgrade)needsthe /etc/postfix/main.cffile
1123 fromapreviousinstallation.Ifthefiledoesnotexist,useinteractiveinstallation(make
1124 install)instead.

1125 Ifyouspecifyname=valueargumentsonthemake installormake upgradecommand


1126 line,thenthesewilltakeprecedenceovercompiled-indefaultsettingsormain.cf
1127 settings.Thecommandmake install/upgrade name=value ...willreplacethe
1128 stringMAIL_VERSIONattheendofaconfigurationparametervaluewiththePostfix
1129 releaseversion.Donottrytospecifysomethinglike$mail_versiononthiscommand
1130 line.Thisproducesinconsistentresultswithdifferentversionsofthemake(1)
1131 command.

1132 2.10.2.7 Configure Postfix


1133 Seehttp://www.postfix.org/postconf.5.htmlforPostfixconfigurationparameters.

1134 Note: The material covered in this section from INSTALL Section 10 is covered in more detail in
1135 the BASIC_CONFIGURATION_README document. The information presented below is
1136 targeted at experienced system administrators.

DNS-Based Email Security Practice Guide DRAFT 45


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

1137 1. Postfixconfigurationfiles
1138 Bydefault,Postfixconfigurationfilesarein/etc/postfix.Thetwomostimportantfiles
1139 aremain.cfandmaster.cf;thesefilesmustbeownedbyroot.Givingsomeoneelsewrite
1140 permissiontomain.cformaster.cf(ortotheirparentdirectories)meansgivingroot
1141 privilegestothatperson.In/etc/postfix/main.cf,youwillhavetosetupaminimal
1142 numberofconfigurationparameters.Postfixconfigurationparametersresembleshell
1143 variables,withtwoimportantdifferences:thefirstoneisthatPostfixdoesnotknowabout
1144 quotesliketheUNIXshelldoes.Youspecifyaconfigurationparameteras:
1145 /etc/postfix/main.cf:
1146 parameter = value
1147 andyouuseitbyputtinga"$"characterinfrontofitsname:
1148 /etc/postfix/main.cf:
1149 other_parameter=$parameter
1150 Youcanuse$parameterbeforeitisgivenavalue(thatisthesecondmaindifferencewith
1151 UNIXshellvariables).ThePostfixconfigurationlanguageuseslazyevaluation,anddoesnot
1152 lookataparametervalueuntilitisneededatruntime.Wheneveryoumakeachangetothe
1153 main.cformaster.cffile,executethefollowingcommandinordertorefresharunningmail
1154 system:
1155 # postfix reload
1156 2. Defaultdomainforunqualifiedaddresses
1157 Firstofall,youmustspecifywhatdomainwillbeappendedtoanunqualifiedaddress(i.e.
1158 anaddresswithout@domain.tld).Themyoriginparameterdefaultstothelocalhostname,
1159 butthatisintendedonlyforverysmallsites.
1160 Some examples (use only one):
1161 /etc/postfix/main.cf:
1162 myorigin = $myhostname(sendmailas"user@$myhostname")
1163 myorigin = $mydomain (sendmailas"user@$mydomain")
1164 3. Specificationofwhatdomainstoreceivelocally
1165 NextyouneedtospecifywhatmailaddressesPostfixshoulddeliverlocally.
1166 Someexamples(useonlyone):
1167 /etc/postfix/main.cf:
1168 mydestination = $myhostname, localhost.$mydomain, localhost
1169 mydestination = $myhostname, localhost.$mydomain,
1170 localhost,$mydomain
1171 mydestination = $myhostname
1172 Thefirstexampleisappropriateforaworkstation,thesecondisappropriateforthemail
1173 serverforanentiredomain.Thethirdexampleshouldbeusedwhenrunningonavirtual
1174 hostinterface.
1175 4. Proxy/NATinterfaceaddresses

DNS-Based Email Security Practice Guide DRAFT 46


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

1176 Theproxy_interfacesparameterspecifiesallnetworkaddressesthatPostfixreceivesmail
1177 onbywayofaproxyornetworkaddresstranslationunit.Youmayspecifysymbolic
1178 hostnamesinsteadofnetworkaddresses.
1179 IMPORTANT:Youmustspecifyyourproxy/NATexternaladdresseswhenyoursystemisa
1180 backupMXhostforotherdomains,otherwisemaildeliveryloopswillhappenwhenthe
1181 primaryMXhostisdown.
1182 Example:hostbehindNATboxrunningabackupMXhost.
1183 /etc/postfix/main.cf:
1184 proxy_interfaces = 1.2.3.4(theproxy/NATexternalnetworkaddress)
1185 5. SpecificationofWhatlocalclientstorelaymailfrom
1186 IfyourmachineisonanopennetworkthenyoumustspecifywhatclientIPaddressesare
1187 authorizedtorelaytheirmailthroughyourmachineintotheInternet.Thedefaultsetting
1188 includesallsubnetworksthatthemachineisattachedto.Thismaygiverelaypermissionto
1189 toomanyclients.Forexample:
1190 /etc/postfix/main.cf:
1191 mynetworks = 168.100.189.0/28, 127.0.0.0/8
1192 6. Specificationofwhatrelaydestinationstoacceptfromstrangers
1193 IfyourmachineisonanopennetworkthenyoumustalsospecifywhetherPostfixwill
1194 forwardmailfromstrangers.Thedefaultsettingwillforwardmailtoalldomains(and
1195 subdomainsof)whatislistedin$mydestination.Thismaygiverelaypermissionfortoo
1196 manydestinations.Recommendedsettings(useonlyone):
1197 /etc/postfix/main.cf:
1198 relay_domains = (donotforwardmailfromstrangers)
1199 relay_domains = $mydomain (mydomainandsubdomains)
1200 relay_domains = $mydomain, other.domain.tld, ...
1201 7. Optional:configureasmarthostforremotedelivery
1202 Ifyou'rebehindafirewall,youshouldsetuparelayhost.Ifyoucan,specifythe
1203 organizationaldomainnamesothatPostfixcanuseDNSlookups,andsothatitcanfallback
1204 toasecondaryMXhostwhentheprimaryMXhostisdown.Otherwisejustspecifya
1205 hard-codedhostname.Someexamplesfollow(useonlyone):
1206 /etc/postfix/main.cf:
1207 relayhost = $mydomain
1208 relayhost = [mail.$mydomain]
1209 Theformenclosedwith[]eliminatesDNSMXlookups.Bydefault,theSMTPclientwilldo
1210 DNSlookupsevenwhenyouspecifyarelayhost.IfyourmachinehasnoaccesstoaDNS
1211 server,turnoffSMTPclientDNSlookupslikethis:
1212 /etc/postfix/main.cf:
1213 disable_dns_lookups = yes
1214 TheSTANDARD_CONFIGURATION_READMEfilehasmorehintsandtipsforfirewalled
1215 and/ordial-upnetworks.

DNS-Based Email Security Practice Guide DRAFT 47


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

1216 8. Createthealiasesdatabase
1217 PostfixusesaSendmail-compatiblealiases(5)tabletoredirectmailforlocal(8)recipients.
1218 Typically,thisinformationiskeptintwofiles:inatextfile/etc/aliasesandinanindexedfile
1219 /etc/aliases.db.Thecommandpostconf alias_mapswilltellyoutheexactlocation
1220 ofthetextfile.First,besuretoupdatethetextfilewithaliasesforroot,postmasterand
1221 postfixthatforwardmailtoarealperson.Postfixhasasamplealiasesfile
1222 /etc/postfix/aliasesthatyoucanadapttolocalconditions.
1223 /etc/aliases:
1224 root: you
1225 postmaster: root
1226 postfix: root
1227 bin: root
1228 etcetera...
1229 Note:thereshouldbenowhitespacebeforethe:.Finally,buildtheindexedaliasesfile
1230 withoneofthefollowingcommands:
1231 # newaliases
1232 # sendmail -bi
1233 9. Settingupchroot
1234 Postfixdaemonprocessescanbeconfigured(viamaster.cf)toruninachrootjail.The
1235 processesrunatafixedlowprivilegeandwithaccessonlytothePostfixqueuedirectories
1236 (/var/spool/postfix).Thisprovidesasignificantbarrieragainstintrusion.Notethat
1237 thisbarrierisnotimpenetrable,buteverylittlebithelps.WiththeexceptionofPostfix
1238 daemonsthatdelivermaillocallyand/orthatexecutenon-Postfixcommands,everyPostfix
1239 daemoncanrunchrooted.
1240 Siteswithhighsecurityrequirementsshouldconsidertochrootalldaemonsthattalktothe
1241 network:thesmtp(8)andsmtpd(8)processes,andperhapsalsothelmtp(8)client.The
1242 default/etc/postfix/master.cffilespecifiesthatnoPostfixdaemonrunschrooted.In
1243 ordertoenablechrootoperation,editthefile/etc/postfix/master.cf.Instructions
1244 areinthefile.
1245 NotealsothatachrooteddaemonresolvesallfilenamesrelativetothePostfixqueue
1246 directory(/var/spool/postfix).Forsuccessfuluseofachrootjail,mostUNIXsystems
1247 requireyoutobringinsomefilesordevicenodes.Theexamples/chroot-setupdirectoryin
1248 thesourcecodedistributionhasacollectionofscriptsthathelpyousetupPostfixchroot
1249 environmentsondifferentoperatingsystems.
1250 Additionally,youneedtoconfiguresyslogdsothatitlistensonasocketinsidethePostfix
1251 queuedirectory.Examplesforspecificsystems:
1252 FreeBSD:
1253 # mkdir -p /var/spool/postfix/var/run
1254 # syslogd -l /var/spool/postfix/var/run/log
1255 Linux,OpenBSD:

DNS-Based Email Security Practice Guide DRAFT 48


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

1256 # mkdir -p /var/spool/postfix/dev


1257 # syslogd -a /var/spool/postfix/dev/log

1258 2.10.3 Postfix Installation and Configuration for use with Dovecot
1259 ThefollowingelementsarenecessaryforsettingupPostfixforDovecot1:
1260 Adomainsuchasmydomain.com
1261 Ahostnameforyourmailserversuchasmail.mydomain.com
1262 AnSSLcertificatethatisvalidformail.mydomain.com

1263 2.10.3.1 Setting up SSL Certificate


1264 ForSSL,youneedacertificateandaprivatekeysavedinalocationsuchas
1265 /etc/ssl/certs/mailcert.pemandthekeyissaved(e.g.,in
1266 /etc/ssl/private/mail.key).Makesurethekeyisonlyreadablebytherootuser.Howto
1267 setupSSLcertificatesforyourwebsiteande-maildependsonyourwebsitestructureandthe
1268 CAyouuse(self-signed,organizational(sub)-ca,orcommercialcaforexample).Creatinga
1269 self-signedtestcertificateisaseasyasexecuting
1270 sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout
1271 /etc/ssl/private/mail.key -out /etc/ssl/certs/mailcert.pem2
1272 andleavingthedefaultvaluesinbyjusthittingenteronallquestionsasked.
1273 MostCAswillrequireyoutosubmitacertificatesigningrequest.(CSR)Youcangenerateone
1274 likethis:
1275 sudo openssl req -nodes -days 365 -newkey rsa:2048 -keyout
1276 /etc/ssl/private/mail.key -out mailcert.csr
1277 Fillintheinformationqueriedproperly,likeinthistranscript:(CheckwiththeCAyouintendto
1278 useonwhatinformationneedstobeintheCSR)
1279 SpecificinstructionsforacquisitionofcertificatesfromCAscanbeobtainedfromtheCA.An
1280 exampleisprovidedat:
1281 https://www.digitalocean.com/community/tutorials/how-to-set-up-a-postfix-e-mail-server-wi
1282 th-dovecot.

1283 2.10.3.2 Setting up DNS


1284 YoustillhavetosetuptheDNSwithanarecordthatpointstoyourmailserverIPandanMX
1285 recordthatpointstothemailservershostname.Instructionsforthestandardconfigurationfor
1286 Postfixcanbefoundathttp://www.postfix.org/STANDARD_CONFIGURATION_README.html.

1.SeeHowToSetUpaPostfixE-MailServerwithDovecot,DigitalOcean,November14,2013.
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-postfix-e-mail-serv-
er-with-dovecot
2.Don'tusethiscertificateinyoursystem.

DNS-Based Email Security Practice Guide DRAFT 49


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

1287 2.11 How to Install and Configure a Thunderbird Mail


1288 Client
1289 ThestartingpointforinstallingThunderbirdcanbefoundat
1290 https://support.mozilla.org/en-US/kb/installing-thunderbird,andtheinitialstepistoclickon
1291 theicondesignatingtheoperatingsystemonwhichThunderbirdisbeinginstalled(Windows,
1292 Mac,orLinux).

1293 2.11.1 Thunderbird Installation Basics and System Requirements


1294 SystemrequirementsforinstallingThunderbird45.2.0onWindows,Mac,andLinuxoperating
1295 systemscanbefoundat
1296 https://www.mozilla.org/en-US/thunderbird/45.2.0/system-requirements/.

1297 2.11.2 Thunderbird Installation and Configuration on Windows


1298 InstructionsforinstallingThunderbirdinWindowsenvironmentscanbefoundat
1299 https://support.mozilla.org/en-US/kb/installing-thunderbird-windows.SelectingDownload
1300 willdownloadThunderbirdonthediskimageThunderbird 45.2.0.dmg.Afterstartingthe
1301 processbyclickingRun,theMozillaThunderbirdSetupWizardwillbestarted.Closingallother
1302 applicationsbeforestartingSetupwillmakeitpossibletoupdaterelevantsystemfileswithout
1303 havingtorebootthecomputer.Afterinstallation,double-clickingontheThunderbirdiconruns
1304 theprogram.

1305 2.11.3 Thunderbird Installation and Configuration on Linux


1306 InstructionsforinstallingThunderbirdonLinuxcanbefoundat
1307 https://support.mozilla.org/en-US/kb/installing-thunderbird-linux.ToinstallThunderbirdusing
1308 thepackagemanager,itisnecessarytorefertothedocumentationoftheLinuxdistribution
1309 you'reusing.CompleteinstructionsforinstallingThunderbirdoutsideofpackagemanagement
1310 maybeavailableatadistributionsupportwebsite(e.g.,InstallingThunderbirdonUbuntu).

1311 2.11.4 Thunderbird Installation and Configuration on Mac


1312 InstructionsforinstallingThunderbirdonMacmachinescanbefoundat
1313 https://support.mozilla.org/en-US/kb/installing-thunderbird-on-mac.TheThunderbird
1314 downloadpageautomaticallydetectstheplatformandlanguageonthecomputeraccessingit.
1315 TodownloadThunderbirdinalanguageotherthantheonesuggested,clickonOther Systems
1316 & Languagesforthelistofavailableeditions.ClickontheOSXinstallationofyourchoiceto
1317 continue.Oncethedownloadiscompleted,thediskimagemayopenbyitselfandmountanew
1318 volumewhichcontainstheThunderbirdapplication.Ifyoudonotseethenewvolume,
1319 double-clicktheThunderbirddmgicontoopenit.AFinderwindowappears,containingthe
1320 Thunderbirdapplication.DragtheThunderbirdicontotheApplicationsfolder.Atthispointyou
1321 canejectthediskimagebyselectingitinaFinderwindowandpressingthecommand+Ekeys
1322 orbyusingtheFinder'sFilemenu,andselectingEject.OpentheApplicationsfolderand
1323 double-clickontheThunderbirdicontostartit.Youmaygetasecuritywarningthat

DNS-Based Email Security Practice Guide DRAFT 50


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

1324 ThunderbirdhasbeendownloadedfromtheInternet.BecauseyoudownloadedThunderbird
1325 fromtheofficialsite,youcanclickOpentocontinue.ThefirsttimeyoustartThunderbirdyou
1326 willbealertedthatitisnotyourdefaultemailapplication.(Thedefaultemailapplicationisthe
1327 programthatopens,forexample,whenyouclickalinkonawebpagetoanemailaddress.)If
1328 youwantThunderbirdtobethedefaultemailapplication,clickYestosetitasyourdefault
1329 mailer.Ifnot(forexampleifyouarejusttryingoutThunderbird)clickNo.

1330 2.11.5 Thunderbird Configuration for use with Microsoft Exchange


1331 ThunderbirdcanbeusedtoaccessMicrosoftExchangeserversthatsupportIMAPorPOP3.The
1332 normalwaytouseThunderbirdwithaMicrosoftExchangeServerrequiresthesystem
1333 administratortoenablethePOP/IMAP/SMTPmailserversthatarebundledwiththatserver.
1334 Otherwise,sinceExchangeusesaproprietaryMAPIprotocol,accessingExchangefrom
1335 Thunderbirdcanrequireapluginorgateway1thatprovidesstandard,compliantprotocolsin
1336 frontofproprietaryExchange(e.g.,DavMail,ExQuilla).
1337 InsettingupThunderbird:
1338 1. OpenThunderbirdandclicktheToolsmenuoption.ClickAccount Settings.ClickAccount
1339 SettingsagaintostarttheprocessfortheExchangeconnection.
1340 2. Enterthefullnameatthefirstwindow.Thisnameiswhatemailrecipientsseeintheir
1341 inbox.Inthefollowingtextbox,enteryouremailaddress.ClicktheNextbutton.
1342 3. SelectIMAP Mail Serverfromthedrop-downwindow.EntertheExchangeservernamein
1343 theIMAP Server Nametextbox.IntheOutgoing Servertextbox,entertheExchangeserver
1344 nameagain.ClicktheNextbutton.
1345 4. ChecktheboxlabeledUsernameandpassword.Enteryourcurrentusernameusedtolog
1346 intothemachine.RemovethecheckmarkintheboxlabeledUsesecureconnection.Click
1347 Finish.TheThunderbirdapplicationisreadytosendandreceiveemailfromtheExchange
1348 server.

1349 2.11.6 Thunderbird Configuration for use with Dovecot/Postfix


1350 Generalstep-by-stepinstructionsforsettingupThunderbirdcanbefoundat
1351 https://products.secureserver.net/email/email_thunderbird.htm(Setting Up Your POP or IMAP
1352 Email Address with Mozilla Thunderbird).
1353 Instructionsforautomaticaccountconfigurationcanbefoundat
1354 https://support.mozilla.org/en-US/kb/automatic-account-configuration.Manualaccount
1355 configurationrequiresthefollowinginformation:
1356 incomingmailserverandport(forexample,pop.example.comandport110or
1357 imap.example.comandport143)
1358 outgoingmailserverandport(forexample,smtp.example.comandport25)

1.Severallinkstofreeandcommercialgatewayandadd-onproductscanbefoundbyusinga
searchenginewiththeargumenthowtoconfigureMicrosoftExchangeserverinThunderbird.

DNS-Based Email Security Practice Guide DRAFT 51


Chapter 2. How to Install and Configure DNS-Protected Email Security Components

1359 securitysettingfortheconnectionwiththeserver(forexample,STARTTLSorSSL/TLSand
1360 whetherornottousesecureauthentication)
1361 Instructionscanbefoundat
1362 https://support.mozilla.org/en-US/kb/manual-account-configuration.

1363 2.11.7 Thunderbird Support


1364 Althoughitisopensourcesoftware,ThunderbirdsupportisavailablefromMozillaandother
1365 sources.

DNS-Based Email Security Practice Guide DRAFT 52


1 3 Device Configuration and Operating
2 Recommendations
3 3.1 Using SSL for Cryptographic Certificate Generation.......................................................... 54
4 3.2 Cryptographic Operations (User Actions)........................................................................... 60
5 3.3 Server-to-Server Encryption Activation and Use................................................................ 67
6 3.4 Utilities and Useful Tools .................................................................................................... 67
7

DNS-Based Email Security Practice Guide DRAFT 53


Chapter 3. Device Configuration and Operating Recommendations

8 Thissectionprovidesadditionalinformationregardingforinstalling,configuringandoperating
9 EmailandDNSsecurityapplications.Section3.1providesspecificrecommendationsregarding
10 certificategeneration.Section3.2describescryptographicoperationandmanagementbyusers
11 onOutlookandThunderbird.Section3.3describessettingupExchangeandPostfixMTAsto
12 provideserver-to-serverencryptionofemail.Section3.4provideslinkstosometoolsand
13 utilitiesthatareusefulininstalling,configuring,provisioning,andmaintainingDNS-basedemail
14 securitysoftware.
15 Itisrecommendedthattheinstallation,configuration,andoperationofDNSserversbe
16 conductedinconformancetoNISTSP800-81-2,theSecure Domain Name System (DNS)
17 Deployment Guide.AppendixDprovidesachecklistformanagementofsecureDNSs.
18 Installation,configuration,andoperationofemailapplicationsshouldfollowthe
19 recommendationsofSP800-177,Trustworthy Email.

20 3.1 Using SSL for Cryptographic Certificate Generation


21 OpenSSLisawidelyusedopen-sourceimplementationofTLS/SSLandsupportingcryptographic
22 librariesforvariousversionofLinux,butcanalsobeusedwithMacOS.OpenSSLalsocontains
23 userutilitiesforgeneratingcryptographickeys,certificaterequests,andX.509certificates.
24 ThereisaFIPS-140approvedversionofrelevantOpenSSLcryptographicmodulesavailablefor
25 usebyfederalagencies.

26 3.1.1 OpenSSL Installation Basics and System Requirements


27 OpenSSLcomponentsandlibrariesareoftenstandardcomponentsinbaseLinuxinstalls,orcan
28 beinstalledusingthebuilt-inrepositorymanagementsystemusedwiththeversionofLinuxin
29 use(e.g.apt-get,yum,rpm,etc.).Administratorsmaywishtoinstallthedeveloperrepositories
30 (*-develor*-src)tomakesurethatallnecessaryheaderfilesareinstalledtosupportserver
31 implementationsthatrelyonOpenSSLforcryptographicsupport.Thelatestversionof
32 OpenSSL,aswellasFIPSapprovedversionsmaynotbeavailableinrepositoriesandmayneed
33 tobebuiltfromsourcefromtheOpensSSLprojecthomepage1.
34 Inadditiontohavingabasesupportedoperatingsystem,OpenSSLrequiresPerl5andaC
35 compileranddevelopmentenvironment(withtoolslikemake)tobesuccessfullycompiledand
36 installed.

37 3.1.1.1 OpenSSL FIPS Approved Installation


38 FederalagenciesorotherorganizationsthatarerequiredtouseFIPS-140approved
39 cryptographicmodulescanuseOpenSSLFIPSapprovedversion.Thesenecessarymodulesare
40 notalwaysavailableviaOS-specificrepositories,butmustbemanuallydownloadedand
41 compiled.Thenewlycompiledlibrariesthenreplaceanyolder,orpre-installedversions2.
42 Serverdaemons(e.g.BINDnamed,postfix,etc.)thatrelyonOpenSSLforcryptographicsupport
43 willthenusetheFIPS-140approvedversionofthelibraries.

1.https://openssl.org/
2.https://wiki.openssl.org/index.php/Compilation_and_Installation#FIPS_Capable_Library

DNS-Based Email Security Practice Guide DRAFT 54


Chapter 3. Device Configuration and Operating Recommendations

44 3.1.1.2 OpenSSL Installation on Mac OS


45 Normally,thereisnoneedtoinstallaseparatesetofcryptographiclibrariesforMacOS.
46 OpenSSLisinstalledinthestandardMacOSdistributionprovidesthesamefunctionality
47 However,ifthereisadesiretoupgradethestandardinstallationanalternativerepositorytool
48 (e.g.homebrew1)maybenecessaryorcertainfilesneedtobechanged2inordertobuild
49 OpenSSLonanApplesystem.

50 3.1.2 OpenSSL Configuration

51 3.1.2.1 Configuration of OpenSSL to act as a Local Certificate Authority (CA)


52 OpenSSLcanbeusedtogeneratecertificatesandactasalocalenterpriseCertificateAuthority
53 (CA).Thisisnotalwaysadvisableasitisverybare-bonedsetoftools.EnterprisesusingOpenSSL
54 astheirCAmusttakegreatcaretoinsurethattherootcertificate(i.e.theCAcertificatethat
55 signsalltheend-entitycertificates)isadequatelyprotected.Compromiseoftherootcertificate
56 privatekeywouldallowanattackertogeneratearbitrarycertificatesforspoofedhostsand
57 services.Howthisrootcertificateprivatekeyisprotectedisbeyondthescopeofthisdocument
58 butshouldincludeadequatephysical,access,andlogicalcontrols.
59 OpenSSLcanbeusedviatheopensslcommandlinetooltogeneratekeypairs,andcertificates
60 forthosekeypairs.Thiscertificategenerationcanbedonebyaddingthecertificatedataonthe
61 commandline,orusingaconfigurationfilefor(organizational)defaultvalues.Forexample,if
62 theorganizationalpolicyisforallcertificatestohavealifetimeofoneyear(365days),that
63 valuecanbesetinaconfigurationfileanddoesnotneedtobesetusingcommandlineoptions
64 unlessthereisaneedtooverridethedefaultforaspeciallygeneratedcertificate.
65 ThegeneralorderinsettingupOpenSSLtooperateanenterpriselocalCA(ortogenerate
66 self-signedcertificates)isto:Generateandsetupconfigurationfiles,generatetheroot
67 certificate,andfinally,generateandsignendentitycertificates.

68 3.1.2.2 The OpenSSL CA Configuration File


69 OnceOpenSSLisinstalledonthesystem,theCAadminneedstofindandedittheopnessl.cnf
70 configurationfile.WherethisfileislocateddependsonhowOpenSSLwasinstalledonthe
71 system.Manyrepositoryinstallationswillputthefileat/etc/ssl/openssl.cnfbutitmay
72 alsobefoundat/usr/sslor/usr/opensslorsomeotherdirectory.
73 Theconfigurationfileisbrokendownintoblocksaroundopensslcommands.Mostofthese
74 blockscanbeleftintheirdefaultvaluesunlessthereisaspecificpolicyreasonforchanging
75 them.ThetwoblocksthatenterpriseCAadminswilllikelyneedtochangeis[CA_default]and
76 [req]whichcontainthedefaultvaluesforcryptographicandhashalgorithms,defaultsizesand
77 lifetimes,andDistinguishedName(country,organizationalname,CommonName,etc.)
78 respectively.Anexamplesnippetoftheconfigurationfileopenssl.cnfisgiveninfigure3.1
79 below.

1.http://brew.sh/
2.https://wiki.openssl.org/index.php/Compilation_and_Installation#Mac

DNS-Based Email Security Practice Guide DRAFT 55


Chapter 3. Device Configuration and Operating Recommendations

80 Thevaluesinthe[CA_defaults]blockdealwiththecomponentsoftheCAitself:the
81 directoriesused,theserialnumberfile,etc.TheseareusedtomanagetheCAitself,notdirectly
82 involvedwiththecryptographicoperationofgeneratingkeypairsandcertificates.CA
83 administratorscansetthesevaluestotheappropriatedirectoriesfortheirenterpriseCA.
84 OpenSSLdoesnotgeneratesomeofthenecessarydirectoriesandfiles(suchasserial,which
85 keepstrackoftheserialnumbersofissuescertificates).Thesewillneedtobecreatedbythe
86 adminusingatexteditororstandardLinuxcommands.
87 Thevaluesinthe[req]blockdealwiththeidentificationdataandcharacteristicsofX.509
88 certificatesgeneratedbytheCA.Thesevalueswillmostlikelyneedtobeeditedbyenterprise
89 CAadministrators.Iftheenterprisecertificatepolicydictatesthatsomevaluesmustbe
90 constantacrosstheorganization,itmakessensetomakethemthedefaultvaluesinthe
91 configurationfile.Forexample,theenterprisealwayswantsitsHQlocationusedasthecountry,
92 state,andlocalityineverycertificateitgenerates.

DNS-Based Email Security Practice Guide DRAFT 56


Chapter 3. Device Configuration and Operating Recommendations

93 Figure 3.1 Example OpenSSL Configuration File

94

95 TheenterpriseCAadmincanthenputtheseentriesintheappropriatelineintheconfiguration
96 file.Forexample:
97 [ req_distinguished_name ]
98 countryName = Country Name (2 letter code)
99 countryName_default = US
100 countryName_min = 2

DNS-Based Email Security Practice Guide DRAFT 57


Chapter 3. Device Configuration and Operating Recommendations

101 countryName_max = 2
102

103 stateOrProvinceName = State or Province Name (full name)


104 stateOrProvinceName_default = District of Columbia
105

106 localityName = Locality Name (eg, city)


107 localityName_default = Washington
108

109 0.organizationName = Organization Name (eg, company)


110 0.organizationName_default = Department of Examples
111 Oncethedefaultvaluesareinplace,theconfigurationfilewillbeusedunlessoverriddeninthe
112 opensslcommandline.Iftheconfigurationfilehasbeenmovedtoanewdirectory,the
113 commandlineoption-configshouldbeincludedintheopensslcommandtopointtothe
114 locationofthenewconfigurationfilelocation.

115 3.1.2.3 Using Linux Environment Variables to Dynamically Set Common Name and
116 SubjectAltName
117 Notallofthevaluescanbesetviathecommandlineoverride.Themostimportantvaluethat
118 anenterpriseCAadminmaywanttochangeisthesubjectAltNameofacertificate.The
119 subjectAltNameisusedtoprovidealternativehostnamesforaserverthatcanbechecked
120 duringPKIXvalidation.Thisallowsoneservertohavemultiplenamesandstillusethesamekey
121 pairforTLS.ThesubjectAltNamedefaultcanbesetintheconfigurationfile,butcannotbeset
122 atthecommandline.
123 OnLinuxsystems,thefollowingcanbeusedintheconfigurationfiletouseenvironment
124 variablesforCommonName(calledCOMNAME)andSubjectAltName(calledSAN).Seebelow:
125 commonName = Common Name (eg, your name or your
126 commonName_default = ${ENV::COMNAME}
127 commonName_max = 64
128

129 subjectAltName = ${ENV::SAN}


130

131 Afterthechangeshavebeenmadetotheconfigurationfile,theCommonNameand
132 SubjAltNamecanbesetdynamically(eitherviacommandlineorappropriatesystemcallin
133 scripts,programs,etc.)tosettheentriesbeforegeneratingacertificate.

134 3.1.3 Certificate Generation

135 3.1.3.1 Generate the Root Certificate


136 Oncetheconfigurationfileisedited,theenterpriseCAadministratormustfirstgeneratearoot
137 certificate.Thiscanbedoneusingtheopensslcommandlinetool,oranincludedsupportscript
138 CA.pl.Thefollowingexamplesusethecommandline,asitisflexibleandcanbeusedvia
139 scriptedsystemcalls(thatsetenvironmentvariables,etc.).Thebasiccommandtogeneratea
140 rootcertificateis:

DNS-Based Email Security Practice Guide DRAFT 58


Chapter 3. Device Configuration and Operating Recommendations

141 >openssl req -config <config file> \


142 -key private/ca.key.pem \
143 -new -x509 -days 7300 -sha256 -extensions v3_ca \
144 -out certs/ca.cert.pem
145 Herethe-configoptionisusedtolistthelocationoftheconfigurationfileinuse.Theuseofthe
146 -daysoptionistoincreasethelifetimeoftherootcertoveranydefaultvalueinthe
147 configurationfile.Therootcertificateisnotlikeend-entityissuedcertificatesandoften
148 requiresmoreconfigurationpossiblemanualinstallationinenterprisesystems,soshouldbe
149 longerlivedforadministrationpurposes(andhighlyprotected).EnterpriseCAadministrators
150 shouldconsultNISTSP800-152,A Profile for U. S. Federal Cryptographic Key Management
151 Systemsforrecommendationsonhowtosetupakeymanagementsystem.

152 3.1.3.2 Generating Intermediate and End-Entity Certificates


153 OncetheCAinfrastructureissetupandtherootcertificateisgenerated,theenterpriseCAcan
154 startgeneratingend-entityand(ifdesired)intermediatecertificates.Intermediatecertificates
155 arejustthat:certificatesthatareextralinksinthePKIXvalidationchaintotherootcertificate.
156 Theyarenotusuallyinstalledastrustanchors,butcanbeusedtosignother(oftenend-entity)
157 certificates.
158 Theadvantageofusingintermediatecertificatesisthattheycanbeusedtocompartmentalize
159 end-entitycertificates,soacompromiseofanintermediatecertmeansthatonlythat
160 certificate(andthoseitsigned)arecompromised,andnottheentireCA.Intermediate
161 certificatesalsoallowCAadministratorstokeeptherootcertificatesafelystoredoffline.Once
162 therootkeyisusedtosigntheintermediatecertificates,itcanbestoredofflineuntilnew
163 intermediatecertificatesareneeded.
164 Thedisadvantagesofusingintermediatecertificatesisthattheyareneededbyallclients
165 wishingtodoPKIXvalidation.Ifaclientcannotfind(orhavestored)allnecessaryintermediate
166 certificates,itcannotvalidateallend-entitycertificates.ProtocolslikeTLSaccountforthisby
167 havingcertificatechainsavailable(end-entityandnecessaryintermediatecertificates),butnot
168 allprotocolsdothis.DANEisanoptionforpublishingintermediatecertificatesintheDNSas
169 intermediatecerts,orasshort-circuitedtrustanchors,dependingonwhichCertificateUsage
170 (CU)parameterisused[RFC6698].
171 Thegeneralcommandtogenerateanewclientkeypairandcertificateis:
172 >openssl req -new -nodes -config <config file> -keyout <key filename>
173 -out \
174 <CSR filename>
175 TheabovecommandwillgenerateakeypairandaCertificateSigningRequest(CSR)forthe
176 newcertificate.The-nodesoptiondisablesthesettingofapasswordfordecryptingtheprivate
177 portionofthekeypair.Thisisimportanttosetforservercertificateswherethereisnoenduser
178 toenterapassword(andtheprivatekeyisneededtosetupaTLSconnection).For
179 intermediatecertificates,thisshouldnotbeset,asthatprivatekeyshouldbeprotected.
180 OncetheCSRisgenerated,itismadeintoacertificate:
181 >openssl ca -config <config file> -out -infiles <CSR filename> -out
182 <cert name>

DNS-Based Email Security Practice Guide DRAFT 59


Chapter 3. Device Configuration and Operating Recommendations

183 Thentheadministratorfollowstheprompt.Administratorsusingintermediatekeysmayalso
184 usethe-key <private key>optiontohaveopensslusethedesiredintermediatekey.
185 Alternatively,theadministratorcouldconfigurethewhichsigningkeytouseintheopenssl
186 configurationfile.Indeed,severalseparateconfigurationfilescouldbeusedifmultiple
187 intermediatekeysareusedfortheenterpriseCA.
188 Oncethenewcertificateandkeypairhavebeengenerated,theymustbeprotectedfrom
189 unauthorizeddisclosure.Theymustbesecuritycommunicatedtoserveradministratorssothe
190 administratorscanconfigurethemforuse.Oncethekeyhasoutliveditslifetime,itmustbe
191 securityretiredandremoved.Theseoperationsshouldbedocumentedaspartofthe
192 enterprisekeymanagementsystem.

193 3.2 Cryptographic Operations (User Actions)


194 Thissectionprovidesinformationregardinguseractionsnecessaryforuserstoinvokedigital
195 signature,encryption,andcryptographiccertificatemanagementfeaturesofOutlookand
196 Thunderbird.Theuser'sexperiencevariesfromrelativelyminimaladditionalimpactin
197 enterpriseenvironmentswithestablishedsystemadministrationandsupporttoasignificant
198 impactinthecaseofindividualself-supportedusers.Wheretheenterpriseofferssystems
199 administrationandsupportservices,theuser'sexperiencewithrespecttoDNSservicesis
200 essentiallyunchanged.Oneexceptionisthat,whereDNSauthenticationfails,emailmessages
201 senttoorbyauserwillnotbedelivered.Thisshouldbeanuncommonexperiencefor
202 correspondentsbutitisuptotheenterpriseDNSadministratortopreventthishappening.
203 Similarly,forserver-to-serverencryption,thesecurityprotectionfeaturesshouldbeessentially
204 transparenttotheuser.

205 3.2.1 Outlook


206 Tousedigitalsignaturesandencryption,boththesenderandrecipientmusthaveamail
207 applicationthatsupportstheS/MIMEstandard.OutlooksupportstheS/MIMEstandard.
208 Instructionsforuser-drivencryptographicfunctionsvaryfromversiontoversionandplatform
209 toplatform.Accessingdigital signatureonanOutlookHelppageusuallyprovidesthenecessary
210 operatorinstructions.TheexampleinstructionsprovidedhereareforOutlook2016for
211 Windows10andOutlookforMac2011.

212 3.2.1.1 Outlook 2016 for Windows 10


213 WhenauserhasbeenissuedanS/MIMEcertificatetheycanimportitintotheOutlook2016's
214 TrustCentertobeusedfordigitalsignatureandencryptionbaseduponthekeyusagesofthe
215 certificate.Whenasmartcardcontainingasecureemaildigitalsignaturecertificateisinserted
216 theWindowsoperatingsystem,theOSwillimportthecertificateintotheuser'spersonal
217 certificatestore.Thiswilloccurwhentheuserinspectsthesmartcardwiththecertutil.exe
218 -scinfocommandorifthefollowinggrouppolicyisenabled:

219 Computer Configuration -> Administrative Templates -> Windows Components -> Smart Card:
220 Turn on certificate propagation from smart card
221 Toviewthecertificatesintheuser'scertificatestore,typecertmgr.msc.

DNS-Based Email Security Practice Guide DRAFT 60


Chapter 3. Device Configuration and Operating Recommendations

222 ConfigureOutlook2106S/MIMESettings:
223 1. OpenOutlook2016.
224 2. ClickonFile,andthenOptions.
225 3. Intheleft-handmenuclickonTrust Center.
226 4. ClickontheTrust Center Settingsbox.
227 5. ClickEmail Securityintheleft-handmenu.
228 6. ClicktheSettingsbuttonwithintheEncryptedEmailsection.
229 7. EnteranamewithintheSecurity Settings Namefield.
230 8. SelecttheSigningCertificatebyclickingontheChoosebuttonforthesigningcertificateand
231 selecttheHash Algorithm.
232 9. IfyouhaveanS/MIMEencryptioncertificateselecttheChoosebuttonfortheencryption
233 certificateandselecttheEncryption Algorithm.
234 10. SelecttheradiobuttonSendtosendthesecertificateswithsignedmessages.
235 TheusercanchoosetoalwaysdigitallysignamessagebyselectingtheAdd digital signature to
236 outgoing messageswithintheTrust Center -> Email Security -> Encrypted Emailmenu.This
237 willdigitallysigneveryoutgoingemail.Toindividuallysignanemail,withinthedraftmessage
238 itselfgotoOptionsandwithinthePermissionsmenuselecttheSignicon.

239

240 3.2.1.2 Outlook for Mac 2011 Certificate Management


241 Iftheuserhasaperson'scertificateinOutlook,heorshecanvalidateadigitallysigned
242 message.1
243 1. ImportingaCertificate
244 a. Atthebottomofthenavigationpane,clickContacts .
245 b. Openthedesiredcontact,andthenclicktheCertificatestab.
246 c. Click ,locatethecertificate,andthenclickOpen.
247 Note:Tosetthedefaultcertificateforacontact,selectthecertificate,click ,and
248 thenclickSet as Default.
249 2. ExportingaCertificate
250 Certificatescanbeexportedinthreeformats:DERencodedX.509,PEM(Base-64encoded
251 X.509),andPKCS#7.TheDERencodedX.509formatisthemostcommon,buttheuser
252 mightwanttoaskwhatformathisorherrecipientrequires.

1.Thisalsoenablestheusertosendthatpersonanencryptedmessage(usertouser).

DNS-Based Email Security Practice Guide DRAFT 61


Chapter 3. Device Configuration and Operating Recommendations

253 a. Atthebottomofthenavigationpane,clickContacts .
254 b. Openthedesiredcontact,andthenclicktheCertificatestab.
255 c. Selectthecertificate,click ,andthenclickExport.Tosettheformatofthe
256 certificate,makeaselectionontheFormatmenu.
257 3. DeletingaCertificate
258 a. Atthebottomofthenavigationpane,clickContacts .
259 b. Openthedesiredcontact,andthenclicktheCertificatestab.
260 c. Selectthecertificate,andthenclick .

261 3.2.1.3 Digital Signature


262 Tousedigitalsignatures(orencryption),boththesenderandrecipientmusthaveamail
263 applicationthatsupportstheS/MIMEstandard.OutlooksupportstheS/MIMEstandard.

264 Note: Before a user starts this procedure, he or she must first have a certificate added to the
265 keychain on his or her computer. For information about how to request a digital certificate from a
266 certification authority, see Mac Help.

267 1. OntheToolsmenu,clickAccounts.
268 Theuserclickstheaccountfromwhichheorshewantstosendadigitallysignedmessage,
269 clicksAdvanced,andthenclickstheSecuritytab.
270 2. UnderDigital signing,ontheCertificatepop-upmenu,theuserclicksthecertificatethathe
271 orshewantstouse.
272 Note:TheCertificatepop-upmenuonlydisplayscertificatesthatarevalidfordigital
273 (signingorencryption)thattheuserhasalreadyaddedtothekeychainforhisorherMac
274 OSXuseraccount.Tolearnmoreabouthowtoaddcertificatestoakeychain,seeMacOS
275 Help.
276 3. Tomakesurethattheusersdigitallysignedmessagescanbeopenedbyallrecipients,even
277 iftheydonothaveanS/MIMEmailapplicationandcannotverifythecertificate,selectthe
278 Send digitally signed messages as clear textcheckbox.
279 4. ClickOK,andthenclosetheAccountsdialogbox.
280 5. Inane-mailmessage,ontheOptionstab,clickSecurity,andthenclickDigitally Sign
281 Message.

282

283 6. Finishcomposingthemessage,andthenclickSend.

DNS-Based Email Security Practice Guide DRAFT 62


Chapter 3. Device Configuration and Operating Recommendations

284 3.2.2 Thunderbird1


285 Forpurposesofillustration,thedescriptionoftheuserexperiencewithThunderbirdalso
286 includedcertificatemanagementrequirements.TheexamplehereshowsbothS/MIMEand
287 PGPexamplesofcertificatemanagement.TheS/MIMEapproachisrecommended.Notethat
288 whenusingOpenPGP,aFIPS140-conformantversionshouldalwaysbeused.

289 3.2.2.1 S/MIME Certificate Management


290 S/MIMEcertificatesareusedfordigitallysignedandencryptede-mailmessages.For
291 informationaboutgettingorcreatingS/MIMEcertificates,see:
292 http://kb.mozillazine.org/Getting_an_SMIME_certificate.
293 1. InstallinganS/MIMEcertificate
294 Important:Beforeausercancreateorimporthisorherowncertificateandprivatekey,he
295 orshemustfirstsetamasterpasswordifthishasnotalreadybeendone.Themaster
296 passwordisneededsothatimportedcertificatesarestoredsecurely.See
297 http://kb.mozillazine.org/Master_passwordforinstructionsforsettingamasterpassword.
298 Theusermayhavehisorherownpersonalcertificateandprivatekeyina.p12or.pfxfile,
299 andmaywishtoimportitintoThunderbird.OnceaMasterPasswordhasbeenset,theuser
300 canimport/installapersonalS/MIMEcertificatefroma.p12or.pfxfilebydoingthe
301 followingsteps.
302 a. OpentheCertificateManagerbygoingtoTools -> Options... -> Advanced ->
303 Certificates -> Manage Certificates....
304 b. GotothetabnamedYour Certificates.
305 c. ClickonImport.
306 d. SelectthePCKS12certificatefile(.pfxor.p12).
307 e. Itwillasktheuserforthemasterpasswordforthesoftwaresecuritydevice.Theuser
308 entershisorhermasterpasswordandclicksOK.
309 f. Next,itwillasktheuserforthepasswordprotectinghisorherpersonalcertificate.If
310 theuser's.p12or.pfxfilehasapassword,theuserentersithere,otherwiseleavethis
311 fieldempty.TheuserthenclicksOK.
312 TheS/MIMEcertificateshouldnowhavebeenimported.Ifthecertificatewasnot
313 trusted,consulttheinstructionsat
314 http://kb.mozillazine.org/Thunderbird_:_FAQs_:_Import_CA_Certificate.
315 2. ConfiguringThunderbirdforusingthecertificatetosignemail
316 GotoTools -> Account Settings...inThunderBird.Thenfindtheaccountwiththeemail
317 addressthatmatchestheemailaddressinthecertificatethathasjustbeeninstalled.The
318 userchoosesSecurityunderthataccountandselectsthecertificatethathasjustbeen
319 installed.Therestoftheoptionsshouldbeselfexplanatory.Whentheuserselectsa
320 certificateinAccountSettings,thatselectiononlyappliestotheaccount'sdefaultidentity
321 oridentities.Thereisnouserinterfaceforspecifyingcertificatesforanaccount'sother

1.Seehttps://support.mozilla.org/en-US/kb/digitally-signing-and-encrypting-messages

DNS-Based Email Security Practice Guide DRAFT 63


Chapter 3. Device Configuration and Operating Recommendations

322 identities.Ifdesired,thiscanbeworkedaroundbyeditingthesettingsmanually,copying
323 thesettingsfromanaccount'sdefaultidentitytosomeotheridentity.Thesettingshave
324 namesendingin:signing_cert_name,sign_mail, encryption_cert_name,and
325 encryptionpolicy.
326 3. UserInstallationofaSelf-SignedS/MIMECertificate
327 IftheSMIMEcertificateinauser's.p12or.pfxfileisaself-signedcertificatefortheuser's
328 ownidentity,thenbeforethatfilecanbeinstalledintothetabnamedYour Certificates,the
329 usermustfirstinstallthatcertificateasacertificateauthorityintheAuthoritiestab.The
330 PKCS12certificatefilewillnotinstallintotheAuthoritiestab.Theuserwillneedacopyofa
331 self-signedcertificatethatdoesnotcontaintheuser'sprivatekey.Thisisusuallyintheform
332 ofa.cerfile.Onewaytoobtainthe.cerformofacertificatefromthe.p12fileistousethe
333 FirefoxAdd-onKeyManagertoextractthe.cercertificatefromthe.p12file.Withthat
334 Add-oninstalledinThunderbird,theusergoestoTools -> Key Manager Toolbox -> Key
335 Manager -> Your Keys,selectshisorherkey,selectsExportandchoosesX.509asfile
336 format.
337 a. GotoTools -> Options... -> Advanced -> Certificates -> Manage Certificates....
338 b. GototheAuthoritiestab.
339 c. ClickonImport.
340 d. Selectthe.cerfile.
341 e. Itwillasktheuserforwhatpurposesheorshewantstotrustthecertificate.Theuser
342 selectsTrust this CA to identify email users.
343 f. ClickOKtocompletetheimport.

344 Note: Thunderbird automatically adds other people's S/MIME certificates to the Other People's
345 tab of a user's Certificate Manager when he or she receives from them a digitally signed
346 message with a valid signature and with an S/MIME certificate issued by a recognized and
347 trusted Certificate Authority (CA). CA certificates that appear in ThunderBird's Authorities tab
348 are recognized, and may also be trusted. CA certificates that do not appear in that tab are
349 considered unrecognized. An S/MIME certificate that was issued by an unrecognized CA will
350 not be automatically added to the Other People's tab of the user's Certificate Manager. If the
351 user attempts to manually import an S/MIME certificate that was issued by an unrecognized CA,
352 nothing will happen--literally. Thunderbird will not even display an error dialog. It will just not
353 import the S/MIME certificate. This is generally not a problem when receiving an S/MIME
354 certificate that was issued by a trusted Certificate Authority (CA), but could be a problem for a
355 certificate that was issued by an unrecognized or untrusted CA, or for a certificate that is
356 self-signed (i.e. it has no CA other than itself). So, before a user can import an S/MIME
357 certificate that is issued by an unrecognized CA or is self-signed, he or she must first acquire
358 and import the certificate for the issuing CA. In the case of a self-signed certificate, a .cer file
359 needs to be acquired from the individual whose certificate the user wishes to add.

360 3.2.2.2 PGP Example of Sending and Receiving Public Keys


361 1. Sendingapublickeyviaemail
362 Tosendsignedmessagestootherpeoplethattherecipientscanvalidate,theusermustfirst
363 sendthemthepublickey:
364 a. Composethemessage.

DNS-Based Email Security Practice Guide DRAFT 64


Chapter 3. Device Configuration and Operating Recommendations

365 b. SelectOpenPGPfromtheThunderbirdmenubarandselectAttach My Public Key.

366

367 c. Sendtheemailasusual.
368 2. Receivingapublickeyviaemail
369 Toverifysignedmessagesfromotherpeople,thepublickeymustbereceivedandstored:
370 a. Openthemessagethatcontainsthepublickey.
371 b. Atthebottomofthewindow,doubleclickontheattachmentthatendsin.asc.(Thisfile
372 containsthepublickey.)
373 c. ThunderbirdautomaticallyrecognizesthatthisisaPGPkey.Adialogboxappears,
374 promptingtheImportorViewofthekey.ClickImporttoimportthekey.

375

376 d. Aconfirmationthatthekeyhasbeensuccessfullyimportedwillbeshown.ClickOKto
377 completetheprocess.
378 3. Revokingakey
379 Iftheprivatekeymayhavebeencompromised(thatis,someoneelsehashadaccessto
380 thefilethatcontainstheprivatekey),revokethecurrentsetofkeysassoonaspossibleand
381 createanewpair.Torevokethecurrentsetofkeys:
382 a. OntheThunderbirdmenu,clickOpenPGPandselectKey Management.

383

DNS-Based Email Security Practice Guide DRAFT 65


Chapter 3. Device Configuration and Operating Recommendations

384 b. Adialogboxappearsasshownbelow.CheckDisplay All Keys by Defaulttoshowallthe


385 keys.
386 c. Right-clickonthekeytoberevokedandselectRevoke Key.
387 d. Adialogboxappearsaskingtheuserifheorshereallywanttorevokethekey.Click
388 Revoke Keytoproceed.
389 e. Anotherdialogboxappearsaskingfortheentryofasecretpassphrase.Enterthe
390 passphraseandclickOKtorevokethekey.
391 Theusersendstherevocationcertificatetothepeoplewithwhomheorshecorrespondsso
392 thattheyknowthattheuser'scurrentkeyisnolongervalid.Thisensuresthatifsomeonetries
393 tousethecurrentkeytoimpersonatetheuser,therecipientswillknowthatthekeypairisnot
394 valid.

395 3.2.2.3 Sending a Digitally Signed Email


396 1. Composethemessageasusual.
397 2. Todigitallysignamessage,selectOpenPGPfromtheThunderbirdmenuandenablethe
398 Sign Messageoption.

399

400 3. Iftheemailaddressisassociatedwithacryptographiccertificate,themessagewillbe
401 signedwiththekeycontainedinthatcertificate.Iftheemailaddressisnotassociatedwith
402 acryptographiccertificate,acertificatemustbeselectedfromalist.
403 4. Sendthemessageasusual.

404 3.2.2.4 Reading a Digitally Signed Email


405 Whenasignedmessageisreceived,andIfThunderbirdrecognizesthesignature,agreenbar
406 (asshownbelow)appearsabovethemessage.
407 Todeterminewhetherornottheincomingmessagehasbeensigned,lookattheinformation
408 barabovethemessagebody.1

409

410 Ifthemessagehasbeensigned,thegreenbaralsodisplaysthetext,Signedmessage.

1.Ifthemessageisalsoencryptedonausertouserbasis,Thunderbirdwillalsoaskfortheentry
ofasecretpassphrasetodecryptthemessage.

DNS-Based Email Security Practice Guide DRAFT 66


Chapter 3. Device Configuration and Operating Recommendations

411 Amessagethathasnotbeensignedcouldbefromsomeonetryingtoimpersonatesomeone
412 else.

413 3.3 Server-to-Server Encryption Activation and Use

414 3.3.1 Office 365 Exchange


415 Server-to-serverencryption(Scenario1)isavailableonExchangeforOffice365.Office365
416 encryptsusers'datawhileit'sonMicrosoftserversandwhileit'sbeingtransmittedbetween
417 theuserandMicrosoft.Office365providescontrolsforendusersandadministratorstofine
418 tunewhatkindofencryptionisdesiredtoprotectfilesandemailcommunications.Some
419 technicallibrarylinksforspecifictopicsareasfollows:
420 InformationonencryptionusingOffice365Exchangecanbefoundat
421 https://technet.microsoft.com/en-us/library/dn569286.aspx.
422 InformationregardingthedifferenttypesofemailencryptionoptionsinOffice365
423 includingOfficeMessageEncryption(OME),S/MIME,InformationRightsManagement
424 (IRM)canbefoundathttps://technet.microsoft.com/en-us/library/dn948533.aspx.
425 Informationregardingdefinitionofrulesregardingemailmessageencryptionand
426 decryptioncanbefoundathttps://technet.microsoft.com/en-us/library/dn569289.aspx.
427 Informationregardingsending,viewing,andreplyingtoencryptedmessagescanbefound
428 athttps://technet.microsoft.com/en-us/library/dn569287.aspx.
429 Serviceinformationformessageencryptioncanbefoundat
430 https://technet.microsoft.com/en-us/library/dn569286.aspx.

431 3.3.2 Postfix


432 PostfixTLSsupportisdescribedathttp://www.postfix.org/TLS_README.html.Postfixcanbe
433 settoencryptalltrafficwhentalkingtoothermailservers.1

434 3.4 Utilities and Useful Tools


435 Thissectionprovideslinkstosometoolsandutilitiesthatareusefulininstalling,configuring,
436 provisioning,andmaintainingDNS-basedemailsecuritysoftware.

1. Setting Postfix to encrypt all traffic when talking to other mailservers, Snapdragon Tech
Blog,August9,2013.http://blog.snapdragon.cc/2013/07/07/setting-postfix-to-encrypt-all-traf-
fic-when-talking-to-other-mailservers/

DNS-Based Email Security Practice Guide DRAFT 67


Chapter 3. Device Configuration and Operating Recommendations

437 3.4.1 DANE Tools

438 3.4.1.1 SMIMEA Retriever Tool


439 TheSMIMEAretrievertool,developedbySantosJhaaspartofthisproject,retrievesSMIMEA
440 recordsfromaDNSforagivenemailaddressandstoresthecertificatesinPKCS12format.This
441 PKCS12storecansubsequentlybeimportedintoanMUAsuchasThunderbirdorOutlook.Since
442 thissoftwareisusedforofflineprovisioningofcertificates,thedeveloperfocusedonselector=0
443 andmatchingtype=0.ItiswrittenusingJava8.

444 3.4.1.2 TLSA Generator


445 ShumonHuque'sonlineTLSAgeneratorgeneratesTLSAresourcerecordsfromacertificateand
446 parametersforwhichpromptsareincluded.Thelinktothetoolis
447 https://www.huque.com/bin/gen_tlsa.

448 3.4.1.3 High Assurance Domain Toolbox


449 NIST'sHighAssuranceDomainToolboxisacollectionofperlscriptsusedtogenerateand
450 formatSMIMEAandTLSARR'sforusewiththeHighAssuranceTestbed.Eachofthesescripts
451 areusedindependentlyandnotallrequiredtobeusedifothersolutionsworkbetter.Thetool
452 canbefoundathttps://github.com/scottr-nist/HAD-tlsa-toolbox.

453 3.4.1.4 Swede


454 SwedeisatoolforuseincreatingandverifyingDANErecords.Thetoolcanbefoundat
455 https://github.com/pieterlexis/swede.

456 3.4.1.5 Hash-slinger


457 Hash-slingerisapackageoftoolscreatedbyPaulWoutersofRedHattomakeiteasytocreate
458 recordsfortheDANEprotocolthatwillallowyoutosecureyourSSL/TLScertificatesusing
459 DNSSEC.ThepackageisavailableforLinuxat:
460 http://people.redhat.com/pwouters/hash-slinger/.

461 3.4.2 DANE Validation Sites and Testers

462 3.4.2.1 NIST DANE Testers


463 NIST'sDANE-testersforRFC6698conformancecanbefoundat
464 http://dane-test.had.dnsops.gov/.

465 3.4.2.2 SMIMEA Test Tool


466 GrierForensics'SMIMEATesttoolcanbefoundathttp://dst.grierforensics.com/#/start.

DNS-Based Email Security Practice Guide DRAFT 68


Chapter 3. Device Configuration and Operating Recommendations

467 3.4.2.3 DANE Validator Online Test Tool


468 TheDANEvalidatoronlinetesttoolfoundathttps://check.sidnlabs.nl/dane/attemptsto
469 performvalidationofaTLSA/PKIpairaccordingtotheDANEInternetstandard.Notethatthe
470 toolautomaticallyselectsPort443andTCP.SNIsupportisincluded.Thetoolsetusesthe
471 ldns-daneexamplefromLDNSfromNLnetLabs.

472 3.4.2.4 DANE SMTP Validator


473 TheDANESMTPValidator,anSMTPDANEtesttool,canbefoundathttps://dane.sys4.de/.

474 3.4.3 Other Test Tools


475 DNSVizisatoolforvisualizingthestatusofaDNSzone.Itwasdesignedasaresourcefor
476 understandingandtroubleshootingdeploymentoftheDNSSecurityExtensions(DNSSEC).It
477 providesavisualanalysisoftheDNSSECauthenticationchainforadomainnameandits
478 resolutionpathintheDNSnamespace,anditlistsconfigurationerrorsdetectedbythetool.
479 ThisDNSSECtesttoolisnotDANEspecific,buthelpful.Itcanbefoundathttp://dnsviz.net/.

DNS-Based Email Security Practice Guide DRAFT 69


1 Appendix A Acronyms
2 ASN AbstractSyntaxNotation
3 AXFR DNSFullZoneTransferQueryType
4 BIND BerkeleyInternetNameDaemon
5 BSD BerkeleySoftwareDistribution
6 CA CertificateAuthority
7 CRL CertificateRevocationList
8 CSR CertificateSigningRequest
9 CU CertificateUsageType
10 DANE DNS-basedAuthenticationofNamedEntities
11 DNS DomainNameSystem
12 DNSSEC DNSSecurityExtensions
13 Email ElectronicMail
14 FIPS FederalInformationProcessingStandard
15 GAL GlobalAddressList
16 HTTP HypertextTransferProtocol
17 IETF InternetEngineeringTaskForce
18 IMAP InternetMessageAccessProtocol
19 IP InternetProtocol
20 ITL InformationTechnologyLaboratory
21 LDAP LightweightDirectoryAccessProtocol
22 MIME MultipurposeInternetMailExtension
23 MTA MailTransferAgent
24 MUA MailUserAgent
25 MX MailExchange(ResourceRecord)
26 NCCoE NationalCybersecurityCenterofExcellence
27 NIST NationalInstituteofStandardsandTechnology
28 NSD NetworkServerDaemon
29 OS OperatingSystem
30 PKI PublicKeyInfrastructure
31 PKIX PublicKeyInfrastructureX.509
32 POP PostOfficeProtocol
33 RFC RequestforComments

DNS-Based Email Security Practice Guide


DRAFT 70
Chapter A.

34 RMF RiskManagementFramework
35 RR ResourceRecord
36 S/MIME Secure/MultipurposeInternetMailExtensions
37 SMIMEA S/MIMECertificateAssociation(ResourceRecord)
38 SMTP SimpleMailTransferProtocol
39 SP SpecialPublication
40 SQL StructuredQueryLanguage
41 TLS TransportLayerSecurity
42 TLSA TLSCertificateAssociation(ResourceRecord)
43 UA UserAgent
44 VLAN VirtualLocalAreaNetwork
45 VM VirtualMachine

DNS-Based Email Security Practice Guide


DRAFT 71
1 Appendix B References
2 Security Requirements for Cryptographic Modules,FederalInformationProcessingStandard
3 (FIPS),FIPS140-2,May2001(includingchangenoticesasof12-03-2002).http://
4 csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
5 Guidelines on Electronic Mail Security;NISTSpecialPublication;SP800-45Ver.2;Tracy,Jansen,
6 Scarfone,Butterfield;February2007.http://csrc.nist.gov/publications/nistpubs/800-
7 45-version2/SP800-45v2.pdf
8 Federal S/MIME V3 Client Profile,NISTSpecialPublication,SP800-49,Chernick,November
9 2002.http://csrc.nist.gov/publications/nistpubs/800-49/sp800-49.pdf
10 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS)
11 Implementations;NISTSpecialPublication;SP800-52Rev.1;Polk,McKay,Chokhani;
12 April2014.http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf
13 Security and Privacy Controls For Federal Information Systems And Organizations,NISTSpecial
14 Publication,SP800-53Rev.4,JointTaskForceTransformationInitiative,April2013.
15 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
16 Recommendation for Key Management: Part 1 - General, NIST Special Publication 800-57 Rev.4,
17 Barker,January2016.http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
18 NIST.SP.800-57pt1r4.pdf
19 Electronic Authentication Guideline;SP800-63-2;Burr,Dodson,Newton,Perlner,Polk,Gupta,
20 Nabbus;August2013.doi:10.6028/NIST.SP.800-63-2
21 Secure Domain Name System (DNS) Deployment Guide,NISTSpecialPublication,SP800-81-2,
22 ChandramouliandRose,September2013.http://nvlpubs.nist.gov/nistpubs/
23 SpecialPublications/NIST.SP.800-81-2.pdf
24 A Framework for Designing Cryptographic Key Management Systems;NISTSpecialPublication;
25 SP800-130;Barker,Branstad,Smid,Chokhani;August2013.http://nvlpubs.nist.gov/
26 nistpubs/SpecialPublications/NIST.SP.800-130.pdf
27 A Profile for U.S. Federal Cryptographic Key Management Systems (CKMS);ThirdDraft;NIST
28 SpecialPublication;SP800-152;Barker,Smid,Branstad;December18,2014.http://
29 nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-152.pdf
30 Trustworthy Email;NISTSpecialPublication;SP800-177;Chandramouli,Garfinkle,Nightingale
31 andRose;DraftPublication;September2016.http://nvlpubs.nist.gov/nistpubs/
32 SpecialPublications/NIST.SP.800-177.pdf
33 X.509 Certificate Policy for the U.S. Federal PKI Common Policy Framework,Version1.21.http://
34 www.idmanagement.gov/documents/common-policy-framework-certificate-policy
35 Domain Names - Concepts And Facilities,RFC1034,Mockapetris,Novenber1987.https://
36 www.ietf.org/rfc/rfc1034.txt
37 Internet X.509 Public Key Infrastructure Certificate and CRL Profile;IETFRFC2459;Housley,
38 Ford,Polk,Solo;January1999.https://www.rfc-editor.org/rfc/rfc2459.txt
39 S/MIME Version 3 Message Specification,IETFRFC2633,Ramsdell,Ed.,June1999.https://
40 www.ietf.org/rfc/rfc2633.txt

DNS-Based Email Security Practice Guide


DRAFT 72
Chapter B.

41 Secret Key Transaction Authentication for DNS (TSIG);RFC2845;Vixie,Gudmundsson,Eastlake,


42 andWellington;May2000.https://www.ietf.org/rfc/rfc2845.txt
43 Secure Domain Name System (DNS) Dynamic Update,RFC3007,Wellington,November2000.
44 https://www.ietf.org/rfc/rfc3007.txt
45 ISO/IEC 9798-3 Authentication SASL Mechanism,RFC3163,ZuccheratoandNystrom,August
46 2001.https://tools.ietf.org/html/rfc3163
47 SMTP Service Extension - Secure SMTP over TLS,RFC3207,Hoffman,February2002.https://
48 www.ietf.org/rfc/rfc3207.txt
49 Cryptographic Message Syntax (CMS),RFC3369,Housley,August2002.https://www.ietf.org/
50 rfc/rfc3369.txt
51 Cryptographic Message Syntax (CMS) Algorithms,RFC3370,Housley,August2002.https://
52 tools.ietf.org/html/rfc3370
53 Threat Analysis of the Domain Name System (DNS),IETFRFC3833,AtkinsandAustein,August
54 2004.https://tools.ietf.org/html/rfc3833
55 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1,CertificateHandlingRFC
56 3850,Ramsdell,July2004.https://tools.ietf.org/html/rfc3850
57 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1,MessageSpecification,
58 RFC3851,Ramsdell,July2004.https://www.ietf.org/rfc/rfc3851.txt
59 DNS Security Introduction and Requirements;RFC4033;Arends,Austein,Larson,Massey,and
60 Rose;March2005.https://www.ietf.org/rfc/rfc4033.txt
61 Resource Records for the DNS Security Extensions;RFC4033;Arends,Austein,Larson,Massey,
62 andRose;March2005.https://www.ietf.org/rfc/rfc4034.txt
63 Protocol Modifications for the DNS Security Extensions;RFC4033;Arends,Austein,Larson,
64 Massey,andRose;March2005.https://www.ietf.org/rfc/rfc4035.txt
65 Lightweight Directory Access (LDAP) Protocol,RFC4511,Sermersheim,Ed.,June2006.https://
66 tools.ietf.org/html/rfc4511
67 Automated Updates of DNS Security (DNSSEC) Trust Anchors,RFC5011,StJohns,September
68 2007.https://tools.ietf.org/html/rfc5011
69 The Transport Layer Security (TLS) Protocol Version 1.2,RFC5246,DierksandRescorla,August,
70 2008.https://tools.ietf.org/html/rfc5246
71 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile;
72 ProposedStandard;IETFRFC5280;Cooper,Santesson,Farrell,Boeyen(Entrust),
73 Housley,Polk;May2008.https://datatracker.ietf.org/doc/rfc5280/
74 Simple Mail Transfer Protocol, IETF RFC 5321,DraftStandard,Kleinstein,October2008.https://
75 tools.ietf.org/html/rfc5321
76 Secure/Multipurpose Internet Mail Extensions (S/MIME),Version3.2,MessageSpecification,
77 ProposedStandard,IETFRFC5751,ISSN:2070-1721,RamsdellandTurner,January
78 2010.https://tools.ietf.org/html/rfc575
79 Multicast Mobility in Mobile IP Version 6 (MIPv6):ProblemStatementandBriefSurvey;RFC
80 5757;Schmidt,Waehlisch,andFairhurst;February2010.https://tools.ietf.org/html/
81 rfc5757

DNS-Based Email Security Practice Guide


DRAFT 73
Chapter B.

82 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
83 Application (ENUM);RFC6116;Bradner,Conroy,andFujiwara;March2011.https://
84 tools.ietf.org/html/rfc6116
85 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE),IETFRFC
86 6394,ISSN:2070-1721,Barnes,October2011.https://tools.ietf.org/html/rfc6394
87 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security Protocol:
88 TLSA,ProposedStandard,IETFRFC6698,ISSN:2070-1721,HoffmanandSchlyter,
89 August2012.https://tools.ietf.org/html/rfc6698
90 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
91 List (CRL) Profile,ProposedStandard,IETFRFC6818,ISSN:2070-1721,Yee,January
92 2013.https://tools.ietf.org/html/rfc6818
93 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities
94 (DANE),RFC7218,Gudmundsson,April2014.https://tools.ietf.org/html/rfc7218
95 The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational
96 Guidance,RFC7671,DukhovniandHardaker,October2015.https://tools.ietf.org/
97 html/rfc7671
98 SMTP security via opportunistic DANE TLS, RFC 7672,DukhovniandHardaker,May26,2015.
99 https://tools.ietf.org/html/rfc7672
100 Using Secure DNS to Associate Certificates with Domain Names For S/MIME, IETFInternetDraft
101 WorkinProgress,draft-ietf-dane-smime-12,HoffmanandSchlyter,July31,2016.
102 https://datatracker.ietf.org/doc/draft-ietf-dane-smime/
103 Domain Name System-Based Security for Electronic Mail,Barker,NationalInstituteofStandards
104 andTechnology'sDakotaConsultingIDIQContractSB1341-12-CQ-0011,TaskOrder15-
105 421Task3Report#2,December17,2016.https://nccoe.nist.gov/sites/default/files/
106 library/NCCoE_DNS-Based_Secure_E-Mail_BB.pdf
107 How To Set Up a Postfix E-Mail Server with Dovecot,DigitalOcean,November14,2013.https://
108 www.digitalocean.com/community/tutorials/how-to-set-up-a-postfix-e-mail-server-
109 with-dovecot
110 "SettingPostfixtoencryptalltrafficwhentalkingtoothermailservers,"Snapdragon Tech Blog,
111 August9,2013.http://blog.snapdragon.cc/2013/07/07/setting-postfix-to-encrypt-all-
112 traffic-when-talking-to-other-mailservers/

DNS-Based Email Security Practice Guide


DRAFT 74
1 Appendix C Platform Operation and
Observations

3 C.1 Operations Scenarios


4 Bothserver-to-serverencryption(Scenario1)andusersignature(Scenario2)ofelectronicmail
5 aredemonstrated.Demonstrationsofthesecurityplatformincludeattemptsbyfraudulent
6 actorstoposeastheoriginatorofemailandman-in-the-middleattackersattemptingtodisrupt
7 thevalidationtheS/MIMEsignature.Eventsareincludedthatinvolveallcomponentsand
8 demonstratethateachoftheMUAscanbeusedwithbothMTAs,andbothMTAscanrunwith
9 eachofthefourDNSstacks.Useofself-signedcertificatesandofcertificatesfromlocaland
10 well-knowncertificateauthoritiesareincluded.Theeventsdonotcoverallpossible
11 combinationsofcomponentsforbothmailoriginationandreceipt,buttheydoinclude
12 demonstrationofbothExchangeandPostfixassenders,allfourDNSservices,andboth
13 ExchangeandPostfixasrecipientsaccessedbybothOutlookandThunderbirdMUAs.Foreach
14 eventidentifiedbelow,weidentifythecomponentsinvolved,operatoractionsrequiredbyboth
15 thesenderandthereceiver,andobservedresults.Forpurposesofavoidingexcessiverepetition
16 intestevents,eacheventincludesdemonstrationofbothscenarios.

17 C.1.1 Server-to-Server Encrypted Email in Scenario 1


18 Anindividualneededtoenterintoanemailexchangewithanindividualinanotherorganization
19 thatrequiredprotectedtransferofinformation.Eachindividualexchangedemailviathe
20 respectiveparentorganizations'mailservers.Usersconnectedtotheirorganizations'respective
21 mailserverswithinaphysicallyprotectedzoneofcontrol.
22 Thepolicyoftheparentorganizationsrequiredencryptionoftheinformationbeingexchanged.
23 Thesecurityaffordedbythecryptographicprocesswasdependentontheconfidentialityof
24 encryptionkeysfromunauthorizedparties.ThemailserverswereconfiguredtouseX.509
25 certificatestoconveykeyingmaterialduringanencryptionkeyestablishmentprocess.
26 DNSSECwasemployedtoensurethateachsendingmailserverconnectedtothelegitimateand
27 authorizedreceivingmailserverfromwhichitsX.509certificatewasobtained.DANEresource
28 recordswereemployedtobindthecryptographickeyingmaterialtotheappropriateserver
29 name.STARTTLSwasemployedtonegotiatethecryptographicalgorithmtobeemployedwith
30 TLSintheemailexchangeinwhichthemessagewastransferred.Encryptionoftheemail
31 messagewasaccomplishedbytheoriginator'semailserver,anddecryptionoftheemail
32 messagewasaccomplishedbytherecipient'semailserver.

33 C.1.2 Signed Email in Scenario 2


34 Scenario2supportsthecaseofanindividualneedingtoenterintoanexchangeofemailthat
35 requiresintegrityprotectionwithanindividualinanotherorganizationthat.Eachindividual
36 exchangedemailviatherespectiveparentorganizations'mailservers.Usersconnectedtotheir
37 organizations'respectivemailserverswithinaphysicallyprotectedzoneofcontrol.

DNS-Based Email Security Practice Guide


DRAFT 75
Chapter C.

38 Thepoliciesoftheparentorganizationsrequiredcryptographicdigitalsignatureofthemessage
39 toprovideintegrityprotectionandsourceauthenticationoftheemailmessage.S/MIMEisa
40 widelyavailableandusedprotocolfordigitallysigningelectronicmail.Eachorganization
41 thereforegeneratedX.509certificatesfortheirusersthatincludedthepublicportionoftheir
42 signaturekeys.ThesecertificateswerethenpublishedintheDNSusingtheappropriateDANE
43 DNSResourceRecord(RR)type.
44 DNSSECwasusedtoprovideassurancethattheoriginatinguser'smailserverconnectedtothe
45 intendedrecipient'smailserver.DANErecordswereemployedtobindthecryptographic
46 certificatestotheappropriateserver(forTLS)andindividualuser(forS/MIME),respectively.
47 TLSwasemployedtoprovideconfidentiality.Digitalsignatureoftheemailmessagewas
48 accomplishedbytheoriginator'semailclient.Validatingthesignature(hencetheintegrityof
49 theauthorizationprovidedintheemailmessage)wasaccomplishedbytherecipient'semail
50 client.

51 C.1.3 Handling of Email from Fraudulent Sender


52 Demonstrationsofthesecurityplatforminbothscenariosincludedanattemptbyafraudulent
53 actortoposeastheoriginatoroftheemail.Whereitwasimplemented,DANEwasusedto
54 exposethefraudulentoriginator'sattempt.

55 C.1.4 Handling of Man-in-the-Middle Attack


56 Demonstrationofthesecurityplatforminbothscenariosalsoincludedaman-in-the-middle
57 attackerattemptingtodisruptthevalidationoftheS/MIMEsignature.WhereDANEwas
58 implemented,theattemptswereshowntofailduetouseofDNSSECandDANErecords.

59 C.1.5 Effects of DNS Errors


60 ADANE-enabledPostfixMTAsentmessagetraffictofourExchangeMTAswithone
61 AuthoritativeServerservingallfourzones.AnNSD4AuthoritativeDNSserverandUnbound
62 recursiveserverwasprovidedforthePostfixMTA,andaSecure64DNSAuthorityandSigner
63 providedtheDNSservicesfortheExchangezones.

64 C.2 Test Sequences


65 Thetestanddemonstrationeventsselectedwerechosentodemonstratethefunctionality
66 availableinbothscenarios,theeffectivenessofavailableDNSservices,andtheinteroperability
67 ofcomponents.Theeventselectionobjectivesalsoincludedkeepingtheeventstoa
68 manageablenumber,whilecapturingsignificantperformanceinformation.Asaresult,several
69 stacksofcontributedMUA,MTA,andDNSservicecomponentsweredemonstratedinthe
70 NCCoElaboratoryenvironment,andrepresentativeNCCoElaboratoryconfigurationswere
71 shownexchangingemailwithtwodifferentexternalsitesusingseveralcryptographiccertificate
72 types(certificatesfromWell-KnownCAs(withTLSARRcertusage(CU)of1),EnterpriseCAs
73 (withTLSARRcertusageof2),andSelf-SignedCAs(withTLSARRcertusageof3).Thefirst
74 externalsiteusedSecure64DNSservices,aPostfixMTA,andaThunderbirdMUAwithanApple

DNS-Based Email Security Practice Guide


DRAFT 76
Chapter C.

75 KeychainUtility.ThesecondexternalsiteusedNLnetLabsDNSservices,aPostfixMTA,anda
76 ThunderbirdMUA.

77 C.2.1 Test Sequence 1: MUA/MTA/DNS Service Combinations


78 Exchanged Signed and Encrypted Email with a Secure64 Site and
79 an NLnet Labs Site
80 AnOutlookMUA,interfacingwithanExchangeMTA,wasconfiguredtouseActiveDirectory
81 andBINDDNSservicesinturn.Eachofthesixconfigurationsexchangedemailwith1)a
82 Secure64MUA/MTA/DNSservicestackthatincludedaPostfixMTAandaThunderbirdMUA
83 runningonaMacOSSystem,and2)anNLnetLabsMUA/MTA/DNSservicestackthatincluded
84 aPostfixMTAandaThunderbirdMUArunningonLinux.Theeventsincludeeventsshowinguse
85 ofWell-KnownCAs(CU-1),EnterpriseCAs(CU=2),andSelf-SignedCertificates(CU=3)forTLS
86 andS/MIME-enabledmailreceiversandS/MIME.Digitalsignatureofthemessageswaslogged.
87 AllmessageswereS/MIMEsigned.Outlookattemptedtoverifyreceivedmessages(Scenario2).
88 Signatureverificationresultswerenoted.DNSnameverificationresultswerenoted.Figure2.1
89 abovedepictstheset-upforlaboratorysupportfortheSecure64destinationvariantofthistest
90 sequence.1

91 C.2.1.1 Active Directory and DNS Server in NCCoE Laboratory


92 TheActiveDirectory,DNSServer,anExchangeMTA,andanOutlookMUAwereconfiguredwith
93 appropriatecertificatesforeachdeploymentscenario.ThesecertificatepoliciesincludeS/
94 MIMEandTLScertificatesfromaWell-KnownCA,certificatesfromanEnterpriseCA,andself-
95 signedcertificates(usingTLSAandSMIMEAparametersCU=1,CU=2,andCU=3respectively).
96 EachofthesethreevariationssentS/MIMEsignedandTLSencryptedemailtoaSecure64site
97 andanNLnetLabssite.TheSecure64sitewasusingaMacBook-hostedThunderbirdMUA,a
98 Postfix/DovecotMTA,DNSCache/DNSAuthorityservicesforprocessingreceivedmessages,
99 andDNSSignerforoutboundmessages.TheNLnetsitewasusinganIntel-hostedThunderbird
100 MUA,aPostfix/DovecotMTA,NSD4andUnboundforprocessingreceivedmessages,and
101 OpenDNSSECforoutboundmessages.EachoftheeventsincludedtheNCCoELaboratory
102 configurationsendingasignedandencryptedmessagetotheremotesites,andasigned
103 responsebeingsentfromeachremotesitetotheNCCoEconfiguration.
104 1. Event 1:OutlookMUAUsinganExchangeMTAusingWell-KnownCAissuedCertificatesfor
105 TLSandS/MIME
106 Expected Outcome:NCCoEOutlookMUAsentatestmessageinanS/MIMEsignedemail
107 usingActiveDirectoryDNSServicesandaWell-KnownCA(CU=1)toSecure64andNLnet
108 Labs,andbothrecipientsreturnedresponsesthatwereS/MIMEsigned.Thesignaturefor
109 thereceivedmessageswasverified.
110 Observed Outcome:Asexpected,themessageswereauthenticatedandalogfilewas
111 saved.
112 2. Event 2:OutlookMUAUsinganExchangeMTAusingEnterpriseCAissuedCertificatesfor
113 TLSandS/MIME

1.TheconnectionsdepictedinFigure2.1areactuallyforthefirstSequence2configuration.Ca-
pabilitiesforSequence1supportareshownasdottedlines.

DNS-Based Email Security Practice Guide


DRAFT 77
Chapter C.

114 Expected Outcome: NCCoEOutlookMUAsentatestmessageinanS/MIMEsignedemail


115 usingActiveDirectoryDNSServicesandanEnterpriseCA(CU=2)toSecure64andNLnet
116 Labs,andbothrecipientsreturnedresponsesthatwereS/MIMEsigned.Thesignaturefor
117 thereceivedmessageswasverified.
118 Observed Outcome:Asexpected,themessageswereauthenticatedandalogfilewas
119 saved.
120 3. Event 3:OutlookMUAUsinganExchangeMTAusingSelf-SignedCertificateforTLSandS/
121 MIME
122 Expected Outcome:NCCoEOutlookMUAsentatestmessageinanS/MIMEsignedemail
123 usingActiveDirectoryDNSServicesandaself-signedTLScertificate(CU=3)toSecure64
124 andNLnetLabs,andbothrecipientsreturnedresponsesthatwereS/MIMEsigned.The
125 signatureforthereceivedmessageswasverified.
126 Observed Outcome:Asexpected,themessagewasauthenticatedandalogfilewassaved.

127 C.2.1.2 BIND in NCCoE Laboratory


128 TheBINDDNSServer,anExchangeMTA,andanOutlookMUAwereconfiguredwith
129 appropriatecertificatesforeachdeploymentscenario.ThesecertificatepoliciesincludeS/
130 MIMEandTLScertificatesWell-KnownCA,certificatesfromanEnterpriseCA,andself-signed
131 certificates(TLSA/SMIMEAparametersCU=1,CU=2,andCU=3respectively).Eachofthese
132 threevariationssentS/MIMEsignedandTLSencryptedemailtoaSecure64siteandanNLnet
133 Labssite.TheSecure64sitewasusingaMacBook-hostedThunderbirdMUA,aPostfix/Dovecot
134 MTA,DNSCache/DNSAuthorityservicesforprocessingreceivedmessages,andDNSSignerfor
135 outboundmessages.TheNLnetsitewasusinganIntel-hostedThunderbirdMUA,aPostfix/
136 DovecotMTA,NSD4andUnboundforprocessingreceivedmessages,andOpenDNSSECfor
137 outboundmessages.EachoftheeventsincludedtheNCCoELaboratoryconfigurationsendinga
138 signedmessagetotheremotesites,andasignedresponsebeingsentfromeachremotesiteto
139 theNCCoEconfiguration.
140 1. Event 4:OutlookMUAUsinganExchangeMTAusingWell-KnownCAissuedCertificatesfor
141 TLSandS/MIME
142 Expected Outcome:NCCoEOutlookMUAsentatestmessageinanS/MIMEsignedemail
143 usingaBINDDNSServerandWell-KnownCA(CU=1)issuedcertificatestoSecure64and
144 NLnetLabs,andbothSecure64andNLnetLabsreturnedaresponsethatwasS/MIME
145 signed.Thesignatureforthereceivedmessageswasverified.
146 Observed Outcome:Asexpected,themessagewasauthenticatedandalogfilewassaved.
147 2. Event 5:OutlookMUAUsinganExchangeMTAusinganEnterpriseCAissuedCertificatesfor
148 TLSandS/MIME
149 Expected Outcome:NCCoEOutlookMUAsendsatestmessageinanS/MIMEsignedemail
150 usingaBINDDNSServerandanEnterpriseCA(CU=2)issuedcertificatestoSecure64and
151 NLnetLabs,andbothSecure64andNLnetLabsreturnedaresponsethatwasS/MIME
152 signed.Thesignatureforthereceivedmessageswasverified.
153 Observed Outcome:Asexpected,themessagewasauthenticatedandalogfilewassaved.
154 3. Event 6:OutlookMUAUsinganExchangeMTAusingSelf-SignedCertificatesforTLSandS/
155 MIME

DNS-Based Email Security Practice Guide


DRAFT 78
Chapter C.

156 Expected Outcome:NCCoEOutlookMUAsentatestmessageinanS/MIMEsignedemail


157 usingaBINDDNSServerandself-signedcertificates(CU=3)toSecure64andNLnet,and
158 bothSecure64andNLnetreturnedaresponsethatwasS/MIMEsigned.Thesignaturefor
159 thereceivedmessageswasverified.
160 Observed Outcome:Asexpected,themessagewasauthenticatedandalogfilewassaved.

161 C.2.2 Test Sequence 2: MUA/MTA/DNS Service Combinations


162 Exchanged Signed and Encrypted Email with an NLnet Labs Site
163 and a Secure64 Site
164 OutlookandThunderbirdMUAs,configuredtouseaPostfixMTAwithDovecotIMAPsupport,
165 wereconfiguredinturntouseBINDandSecure64'sDNSAuthority,DNSCache,andDNSSigner
166 implementations.EachofthesixconfigurationsexchangedemailwithaSecure64sitethat
167 includedaThundebirdMUA,DNSCache/DNSSigner/DNSAuthorityDNSservices,andPostfix/
168 DovecotMTAandanNLnetLabsMUA/MTA/DNSservicestackthatincludedaThundebird
169 MUA,NSD4,Unbound,andOpenDNSSECDNSservicesandaPostfix/DovecotMTA.Thetest
170 eventsincludeusingWell-KnownCAissued(TLSA/SMIMEACU=1),EnterpriseCAissued(CU=2),
171 andSelf-SignedCertificates(CU=3).EmailmessagesbetweenMTAswereencryptedand
172 successfullydecrypted.(Scenario1).Signatureandencryptionwerelogged.Allmessageswere
173 S/MIMEsigned.Outlookattemptedtoverifyreceivedmessages(Scenario2).Signature
174 verificationresultswerenoted.DNSnameverificationresultswerenoted.Figure2above
175 depictstheset-upforlaboratorysupportforthistestsequence,withconnectionsselectedfor
176 Event7below.

177 C.2.2.1 BIND and Postfix/Dovecot in NCCoE Laboratory


178 Outlook,thenThunderbirdmailclientswereconfiguredtousePostfix/DovecotMTAsandBIND
179 DNSservers.EachofthesethreeconfigurationssentS/MIMEsignedandTLSencryptedemailto
180 aSecure64siteandanNLnetLabssite.TheSecure64sitewasusingaThunderbirdMUAusing
181 Secure64'sAppleKeyChainUtilitytoolthatallowsahosttoobtainX.509certificatesviaof
182 DANERRs,DNSCache/DNSSigner/DNSAuthorityDNSservices,andaPostfix/DovecotMTAfor
183 mail.TheNLnetLabssitewasusingaThunderbirdMUA,aPostfix/DovecotMTA,andNSD4,
184 Unbound,andOpenDNSSECDNSServices.EachofthethreeeventsincludedtheNCCoE
185 LaboratoryconfigurationsendingaS/MIMEsignedandTLSencryptedmessagetotheSecure64
186 andNLnetLabssites,andsignedandencryptedresponsesbeingsentfromtheSecure64and
187 NLnetLabssitetotheNCCoE.
188 1. Event 7:OutlookMUAUsingaPostfix/DovecotMTAandWell-KnownCAIssuedCertificates
189 forTLSandS/MIME
190 Expected Outcome:NCCoEOutlookMUAusingBINDforDNSsentatestmessageinanS/
191 MIMEsignedemailtoSecure64andNLnetLabs.Secure64andNLnetLabsreturned
192 responsesthatwereS/MIMEsignedandTLSencrypted.Thereceivedmessageswere
193 successfullydecrypted,andthesignatureswereverified.AllS/MIMEandMTATLS
194 certificatesinthistestwereissuedfromawell-knownCAandTLSA/SMIMEARRCertificate
195 Usageparametersetto1.
196 Observed Outcome:Asexpected,themessagewasauthenticatedanddecrypted,andalog
197 filewassaved.

DNS-Based Email Security Practice Guide


DRAFT 79
Chapter C.

198 2. Event 8:ThunderbirdMUAUsingaPostfix/DovecotMTAandEnterpriseCAIssued


199 CertificatesforTLSandS/MIME
200 Expected Outcome:NCCoEThunderbirdMUAusingBINDforDNSsentatestmessageinan
201 S/MIMEsignedemailtoSecure64andNLnetLabs.Secure64andNLnetLabsreturned
202 responsesthatwereS/MIMEsignedandTLSencrypted.Thereceivedmessageswere
203 successfullydecrypted,andthesignatureswereverified.AllS/MIMEandMTATLS
204 certificatesinthistestwereissuedfromanenterpriselocalCAandTLSA/SMIMEARR
205 CertificateUsageparametersetto2.
206 Observed Outcome:Asexpected,themessagewasauthenticatedanddecrypted.andalog
207 filewassaved.
208 3. Event 9:ThunderbirdMUAUsingaPostfix/DovecotMTAandSelf-SignedCertificates
209 Expected Outcome:NCCoEThunderbirdMUAusingBINDforDNSsentatestmessageinan
210 S/MIMEsignedemailtoSecure64andNLnetLabs.Secure64andNLnetLabsreturned
211 responsesthatwereS/MIMEsignedandTLSencrypted.Thereceivedmessageswere
212 successfullydecrypted,andthesignatureswereverified.AllS/MIMEandMTATLS
213 certificatesinthistestwereself-signedandTLSA/SMIMEARRCertificateUsageparameter
214 setto3.
215 Observed Outcome:Asexpected,themessagewasauthenticatedanddecrypted,andalog
216 filewassaved.

217 C.2.2.2 Postfix/Dovecot with DNS Authority, DNS Cache, and DNS Signer in NCCoE
218 Laboratory
219 AThunderbirdclientwasconfiguredtouseDNSAuthority,DNSCache,andDNSSignerServers
220 anduseaPostfix/DovecotMTA.EachofthesethreeconfigurationssentS/MIMEsignedandTLS
221 encryptedemailtoaSecure64siteandanNLnetLabssite.TheSecure64sitewasusinga
222 ThunderbirdMUAthatemployedSecure64'sAppleKeyChainUtilitytoolthatallowsahostto
223 obtainX.509certificatesviaofDANERRs,DNSCache/DNSSigner/DNSAuthorityDNSservices,
224 andaPostfix/DovecotMTAformail.TheNLnetLabssitewasusingaThunderbirdMUA,a
225 Postfix/DovecotMTA,andNSD4,Unbound,andOpenDNSSECDNSServices.Eachofthethree
226 eventsincludedtheNCCoELaboratoryconfigurationsendinganS/MIMEsignedandTLS
227 encryptedmessagetotheSecure64andNLnetLabssites,andsignedandencryptedresponses
228 beingsentfromtheSecure64andNLnetLabssitetotheNCCoE.
229 1. Event 10:ThunderbirdMUAUsingaPostfix/DovecotMTAandWell-KnownCAIssued
230 CertificatesforTLSandS/MIME
231 Expected Outcome:NCCoEThunderbirdMUAusingDNSAuthority/Cache/SignerDNS
232 ServicesandaPostfixMTAsentatestmessageinanS/MIMEsignedemailtoSecure64and
233 NLnetLabs.Secure64andNLnetLabsreturnedthatamessagethatwehadS/MIMEsigned
234 andTLSencrypted.Thereceivedmessagesweresuccessfullydecrypted,andthesignatures
235 wereverified.Allcertificatesinthistestwereissuedfromawell-knownCAandTLSA/
236 SMIMEARRCertificateUsageparametersetto1.
237 Observed Outcome:Asexpected,themessagewasauthenticatedanddecrypted,andalog
238 filewassaved.
239 2. Event 11:ThunderbirdMUAUsingaPostfix/DovecotMTAandEnterpriseCAIssued
240 CertificatesforTLSandS/MIME

DNS-Based Email Security Practice Guide


DRAFT 80
Chapter C.

241 Expected Outcome:NCCoEThunderbirdMUAusingDNSAuthority/Cache/SignerDNS


242 ServicesandaPostfixMTAsentatestmessageinanS/MIMEsignedemailtoSecure64and
243 NLnetLabs.Secure64andNLnetLabsreturnedamessagethatwehadS/MIMEsignedand
244 TLSencrypted.Thereceivedmessagesweresuccessfullydecrypted,andthesignatures
245 wereverified.AllcertificatesinthistestwereissuedfromanenterpriseCAandTLSA/
246 SMIMEARRCertificateUsageparametersetto2.
247 Observed Outcome:Asexpected,themessagewasauthenticatedanddecrypted,andalog
248 filewassaved.
249 3. Event 12:ThunderbirdMUAUsingaPostfix/DovecotMTAandSelf-SignedCertificatesfor
250 TLSandS/MIME
251 Expected Outcome:NCCoEThunderbirdMUAusingDNSAuthority/Cache/SignerDNS
252 ServicesandaPostfixMTAsentatestmessageinanS/MIMEsignedemailtoSecure64and
253 NLnetLabs.Secure64andNLnetLabsreturnedamessagethatwehadS/MIMEsignedand
254 TLSencrypted.Thereceivedmessagesweresuccessfullydecrypted,andthesignatures
255 wereverified.Allcertificatesinthistestwereself-signedandTLSA/SMIMEARRCertificate
256 Usageparametersetto3.
257 Observed Outcome:Asexpected,themessagewasauthenticatedanddecrypted,andalog
258 filewassaved.

259 C.2.3 Sequence 3: Fraudulent DNS Address Posing as Valid DNS


260 Address Contacting Recipient MTAs
261 FraudulentlyS/MIMEsignedemailwassentfromamalicioussendertorecipientsusing
262 OutlookandThunderbirdMUAsconfiguredtouseExchangeandPostfixasMTAs.TheOutlook/
263 ExchangeconfigurationusedActiveDirectoryasitsDNSserver.Theconfigurationsemploying
264 Postfix/DovecotMTAsweredemonstratedwitheachoftheotherthreecontributedDNS
265 Services.Inoneevent,theThunderbirdMUAemployedanAppleKeyChainUtilitytoolthat
266 allowsahosttoobtainX.509certificatesviaofDANERRs.Alleventswereconductedusingwell-
267 knownCAandEnterpriseCA-issuedcertificatesfortheimpersonatedsender.Thefraudulent
268 siteattemptedtospoofavalidsendingdomainbelongingtoaSecure64sitethatwas
269 configuredwithDNSAuthority/Cache/SignerDNSservices,aPostfix/DovecotMTA,and
270 Thunderbird1equippedwiththeAppleKeyChainutility.AnOutlook/Exchange/ActiveDirectory
271 set-upactedasthefraudulentsite.Theemailexchangebetweenorganizationswascarriedover
272 TLS,andtheemailmessagewasS/MIMEsignedonthefraudulentusers'clientdevice.Theset-
273 upforthissequenceisdepictedinfigureC.1below.

274 C.2.3.1 Spoofing Attempts Against Exchange and Postfix/Dovecot Configurations Using
275 Enterprise CA Issued Certificates (CU=1)
276 Thetargetset-upiscomprisedof(alternatively):ActiveDirectoryandDNSServer,BINDDNS
277 Server,NLnetLabsDNSServices,andSecure64DNSserviceswithMicrosoftOutlook/Exchange,
278 Outlook/Postfix/Dovecot,andThunderbird/Postfix/Dovecotmailconfigurations.Forpurposes
279 ofthisdemonstration,twocertificateswereissuedforeachdomain.Oneofthesewasvalidand
280 publishedasaDNSSECsignedSMIMEARRinthetarget'szone.Thesecond(spoofed)certificate

1.Technically,thisshouldn'tmatter.Secure64isn'tsendingthemail,sotheMUAisn'tinvolved.

DNS-Based Email Security Practice Guide


DRAFT 81
Chapter C.

281 isnotintheDNS.Thefraudulentsitepossessedthespoofedcertificatesand,posingasavalidSecure64site,attemptedtosendemailsto
282 theNCCoELaboratorytargetconfigurations.TheemailandDNStransactionswereloggedineachcase,andtheresultsareprovided
283 below.

284 Figure C.1 Fraudulent DNS Address Spoofing Configurations

285 [

286 1. Event 13:OutlookMUA,ExchangeMTA,andActiveDirectoryDNSServices

DNS-Based Email Security Practice Guide


DRAFT 82
Chapter C.

287 Expected Outcome:UsingS/MIME,Outlookvalidatedthemessagefromtheattacker(as


288 DANEisnotenabledinOutlookatthistime).
289 Observed Outcome:Asexpectedandalogfilewassaved.
290 2. Event 14:ThunderbirdMUA,Postfix/DovecotMTAandNLnetLabsDNSServices
291 Expected Outcome:UsingS/MIMEandDANE,Thunderbirdrecognizesthatthecertificate
292 hasnotbeenvalidatedanddoesnotdeliverthemessagetotheuser.Thunderbirdwillflag
293 thesignatureasinvalid.
294 Observed Outcome:Asexpectedandalogfilewassaved.
295 3. Event 15:ThunderbirdMUA,Postfix/DovecotMTAandSecure64DNSServices
296 Expected Outcome:UsingS/MIMEandDANE,ThunderbirdwiththeAppleKeyChainUtility
297 recognizesthatthecertificatehasnotbeenvalidatedanddoesnotdeliverthemessageto
298 theuser.
299 Observed Outcome:Asexpectedandalogfilewassaved.

300 C.2.3.2 Spoofing Attempts Against Exchange and Postfix/Dovecot Configurations Using Self-
301 Signed Certificates (CU=3)
302 Thetargetset-upisconfiguredtouseActiveDirectorywithOutlookandExchange;andina
303 separatesetoftests:BINDandNLnetLabsDNSServices(alternatively)wereconfiguredwitha
304 ThunderbirdMUAandaPostfix/DovecotMTA.Thefraudulentsite,posingasavalidSecure64
305 site,attemptedtosendanemailtotheNCCoELaboratorytarget.TheemailandDNS
306 transactionswereloggedineachcase,andtheresultsareprovidedbelow.
307 1. Event 16:PostfixMTAUsinganActiveDirectoryDNSService
308 Expected Outcome:UsingonlyS/MIME,Outlookwillfailtovalidatethemessagefromthe
309 attackerasitwassignedbyanuntrustedroot,butnotmarkedasapossibleattack.
310 Observed Outcome:Asexpectedandalogfilewassaved.
311 2. Event 17:PostfixMTAUsingaBINDDNSService
312 Expected Outcome:UsingS/MIMEandDANE,ThunderbirdwiththeAppleKeyChainUtility
313 recognizesthatthecertificatehasnotbeenvalidatedanddoesnotdeliverthemessageto
314 theuser.
315 Observed Outcome:Asexpectedandalogfilewassaved.
316 3. Event 18:PostfixMTAUsinganNLnetDNSService
317 Expected Outcome:UsingS/MIMEandDANE,ThunderbirdwiththeAppleKeyChainUtility
318 recognizesthatthecertificatehasnotbeenvalidatedanddoesnotdeliverthemessageto
319 theuser.
320 Observed Outcome:Asexpectedandalogfilewassaved.

DNS-Based Email Security Practice Guide


DRAFT 83
Chapter C.

321 C.2.4 Sequence 4: Man-in-the-Middle Attack on Postfix-to-Postfix


322 Connection
323 AnNCCoEsystemattemptedtosendaTLSprotectedemailfromExchangeandPostfixMTAs(in
324 turn)toanexternalPostfixMTAusingDNSAuthority/Cache/SignerforDNSservices.TheNCCoE
325 ExchangeMTAusedActiveDirectoryDNSServices,andthePostfix/DovecotMTAusedBINDand
326 NSD4/Unbound/OpenDNSSECDNSservices.AS/MIMEsignedemailwassenttoanexternal
327 PostfixMTA.FoureventswereconductedusingWell-KnownCAissuedcertificates,fourevents
328 wereconductedusingEnterpriseCAissuedcertificates(TLSA/SMIMEARRparameterofCU=2)
329 forTLSandS/MIMEonthereceiverside,andthreeeventswereconductedusingself-signed
330 certificates(TLSA/SMIMEARRparameterofCU=3)forTLSandS/MIMEonthereceiverside.An
331 Outlook/Exchange/ActiveDirectorystackactedasaman-in-the-middleandattemptedto
332 interceptthemessage.FigureC.2depictstheconfigurationforaman-in-the-middle
333 demonstration.Notethatthesenderisbeingmisdirectedtoamaliciousemailserveronly.This
334 istosimulatealowerlevelattackwhereemailissent(viaroutehijackingorsimilarlowlevel
335 attack)toaMan-in-the-Middle.FigureC.2depictstheconfigurationsusedwiththe
336 Thunderbird/Postfix/Dovecot/Bindoptionselected.

337 C.2.4.1 Man-in-the-Middle Attack when Senders and Receivers use Well-Known CA Issued
338 Certificates (CU=1)
339 Thesenderset-upwascomprisedofActiveDirectoryandDNSServer,BINDDNSService,or
340 NLnetLabsDNSServiceswithOutlookandThunderbirdMUAsusinganExchangeMTA.Inthe
341 fourthevent,thesenderisaThunderbirdMUAwithaSecure64AppleKeyChainutilityutilizing
342 NSD4/Unbound/OpenDNSSECDNSservicesandaPostfix/DovecotMTA.EnterpriseCAissued
343 certificatesareusedonthereceiversideforTLS.Eachofthefourconfigurationsattemptsto
344 initiateanemailexchangewithanexternalSecure64site.Theman-in-the-middle,anOutlook/
345 Exchange/ActiveDirectorystack,attemptstospooftheintendedreceiverandaccepttheemail.
346 TheemailandDNStransactionswereloggedineachcase,andtheresultsareprovidedbelow.

DNS-Based Email Security Practice Guide


DRAFT 84
Chapter C.

347 Figure C.2 Man-in-the-Middle Event Configurations

348

349 1. Event 19:OutlookMUA,ExchangeMTA,andActiveDirectoryDNSServiceasSender


350 Expected Outcome:ThesendingMTAfailstodetectthespoofing.ThemailconnectiontotheMTAisestablishedandmailis
351 transferred.
352 Observed Outcome:Asexpectedandalogfilewassaved.

DNS-Based Email Security Practice Guide


DRAFT 85
Chapter C.

353 2. Event 20:ThunderbirdMUA,ExchangeMTA,andBINDDNSServiceasSender


354 Expected Outcome:ThesendingMTAfailstodetectthespoofing.Themailconnectionto
355 theMTAisestablishedandmailistransferred.
356 Observed Outcome:Asexpectedandalogfilewassaved.
357 3. Event 21:ThunderbirdMUA,PostfixMTAandNSD4/Outbound/OpenDNSSECDNSServices
358 asSender
359 Expected Outcome:TheMUAusingaSMIMEAutilitywasabletodetectthefraudulent
360 emailandmarktheemailasnotvalidated.
361 Observed Outcome:Asexpectedandalogfilewassaved.
362 4. Event 22:ThunderbirdMUAwithSecure64AppleKeyChainUtility,Postfix/DovecotMTA
363 andDNSAuthority/Cache/SignerDNSServices
364 Expected Outcome:TheMUAusingaSMIMEAutilitywasabletodetectthefraudulent
365 emailandmarktheemailasnotvalidated.
366 Observed Outcome:Asexpectedandalogfilewassaved.

367 C.2.4.2 Man-in-the-Middle Attack when Senders and Receivers use Enterprise CA Issued
368 Certificates (CU=2)
369 Thesenderset-upwascomposedofActiveDirectoryandDNSServer,BINDDNSService,or
370 NLnetLabsDNSServiceswithOutlookandThunderbirdMUAsusinganExchangeMTA.Inthe
371 fourthevent,thesenderisaThunderbirdMUAwithaSecure64AppleKeyChainutilityutilizing
372 NSD4/Unbound/OpenDNSSECDNSservicesandaPostfix/DovecotMTA.EnterpriseCAissued
373 certificatesareusedonthereceiversideforTLS.Eachofthefourconfigurationsattemptsto
374 initiateanemailexchangewithanexternalSecure64site.Theman-in-the-middle,anOutlook/
375 Exchange/ActiveDirectorystack,attemptstospooftheintendedreceiverandaccepttheemail.
376 TheemailandDNStransactionswereloggedineachcase,andtheresultsareprovidedbelow.
377 1. Event 23:OutlookMUA,ExchangeMTA,andActiveDirectoryDNSServiceasSender.
378 Expected Outcome:ThesendingMTAfailstodetectthespoofing.Themailconnectionto
379 theMTAisestablishedandmailtransferred.
380 Observed Outcome:Asexpectedandalogfilewassaved.
381 2. Event 24:ThunderbirdMUA,ExchangeMTA,andBINDDNSServiceasSender.
382 Expected Outcome:ThesendingMTAfailstodetectthespoofing.Themailconnectionto
383 theMTAisestablishedandmailtransferred.
384 Observed Outcome:Asexpectedandalogfilewassaved.
385 3. Event 25:ThunderbirdMUA,PostifxMTAandNSD4/Outbound/OpenDNSSECDNSServices
386 asSender
387 Expected Outcome:ThePostfixMTAdetectsthespoofingandclosestheSMTPconnection
388 beforetheemailissent.
389 Observed Outcome:AsExpected.
390 4. Event 26:ThunderbirdMUAwithSecure64AppleKeyChainUtility,Postfix/DovecotMTA
391 andDNSAuthority/Cache/SignerDNSServices

DNS-Based Email Security Practice Guide


DRAFT 86
Chapter C.

392 Expected Outcome:ThepostfixMTAdetectsthespoofingandclosestheSMTPconnection


393 beforetheemailissent.
394 Observed Outcome:AsExpected.

395 C.2.4.3 Man-in-the-Middle With Self-Signed Certificates (CU=3)


396 ThesenderusesanOutlookandThunderbirdMUAssendingmailthroughaPostfix/Dovecot
397 MTAandusing(inturn):ActiveDirectoryandDNSServer,BINDDNSServer,andNLnetLabsDNS
398 Services.Self-signedcertificatesareusedonthelegitimatereceiverside(TLSARRparameter
399 CU=3)forTLS.Eachofthethreeconfigurationsattemptstoinitiateanemailexchangewithan
400 externalSecure64site.Theman-in-the-middle,anOutlook/Exchange/ActiveDirectorystack,
401 attemptstointercepttheemailfromtheNCCoELaboratoryConfigurationbyactingasaMan-
402 in-the-Middle.TheemailandDNStransactionswereloggedineachcase,andtheresultsare
403 providedbelow.
404 1. Event 27:PostfixMTAUsinganActiveDirectoryDNSService
405 Expected Outcome:TLSAdetectsspoofing.ThemailconnectiontotheMTAisestablished
406 butbreaksbeforethemailistransferred.
407 Observed Outcome:Asexpectedandalogfilewassaved.
408 2. Event 28:ThunderbirdMUA,ExchangeMTA,andBINDDNSService
409 Expected Outcome:Exchangefailstodetecttheman-in-the-middleandsendstheemail.
410 Observed Outcome:Asexpectedandalogfilewassaved.
411 3. Event 29:ThunderbirdMUAwithSecure64AppleKeyChainUtility,ExchangeMTAand
412 NSD4/Outbound/OpenDNSSECDNSServices
413 Expected Outcome:Exchangefailstodetecttheman-in-the-middleandsendstheemail.
414 Observed Outcome:Asexpectedandalogfilewassaved.

415 C.2.5 Sequence 5: Effects of DANE Errors


416 InSequence5,ADANE-enabledPostfixMTAsentmessagetraffictofourotherpostfixMTAs.
417 SeefigureC.3.AsingleBINDinstancewassetuptoservetheTLSAandARRsforthefour
418 receivers.OneofthereceivingMTAsdidnotemployDANE.ThesecondemployedDANEwitha
419 validTLSAwiththecertificateusagefield1setto3.ThethirdemployedaTLSAwithacertificate
420 usagefieldof2,butwithanincomplete(i.e.bad)PKIcertificationpath(generatingaPKIX
421 validationfailure).TheTLSAcontainedalocalenterprisetrustanchor,buttheserverdidnot
422 havethefullcertificatechain(missingintermediatecertificate).ThefinaloneemployedDANE
423 withaTLSARRusingCertificateUsageof3,buttherewasamismatchbetweentheservercert
424 andTLSARR(generatingaDANEvalidationfailure).

1.RFC6698,TheDNS-BasedAuthenticationofNamedEntities(DANE)TransportLayerSecurity
(TLS)Protocol:TLSA,Section2.1.1.https://tools.ietf.org/html/rfc6698#section-2.1.1

DNS-Based Email Security Practice Guide


DRAFT 87
Chapter C.

425 C.2.5.1 Event 30: DNS/DANE Error Results


426 Thetestsequencewassetupasdescribedabove.ThesendingMTAwassetwithdifferentTLS
427 andDANErequirementsconfiguration.PostfixcanbeconfiguredfordifferentlevelsofTLS
428 andDANEprocessingandreliance.InthePostfixconfigurationfile(main.cf)theoptiontoturn
429 onDANEprocessingis:
430 smtp_tls_security_level = none | may | encrypt | dane | dane-only | fingerprint
431 | verify | secure
432 Forthistest,onlynone,may,daneanddane-onlyarerelevant.Thesevaluesaffecthowpostfix
433 establishanduseTLSwhensendingemail:
434 none:ThesenderdoesnotuseTLSevenwhenofferedoravailable.Emailisalwayssentin
435 plaintext.
436 may:ThesenderusesTLSopportunisticallywhenavailable.Noeffortwillbemadeto
437 validatetheserverpeercertificate,butwillbeusedregardless.
438 encrypt:ThesenderwillonlysendmailwhenTLSisavailable,eveniftheserverpeer
439 certificateisonvalidated.IfSTARTTLSisnotoffered,mailisdeferred.
440 dane:ThesenderattemptstouseTLSwhenoffered,andqueriesforTLSARRstohelp
441 validatetheserverpeercertificate.Mailisstillsentifthevalidationfails,sothisis
442 sometimesreferredtoasopportunisticDANE.
443 dane-only:ThesenderonlysendsmailwhenTLSisoffered,andthereisavalidTLSARR
444 found.Otherwise,mailisdeferred.

445 Figure C.3 Failed Delivery Logs

446

DNS-Based Email Security Practice Guide


DRAFT 88
Chapter C.

447 Expected Outcome:Littleornothingappearsinthesender'slogsformessagessenttoeither


448 theMTAnotemployingTLSortheemployingavalidTLSA.ThegrowthratesforlogsfortheMTA
449 thatemploysaTLSAwithacertificateusagefieldof1,butwithaPKIXfailureandtheonethat
450 employsmismatchedservercert/TLSA(i.e.DANEvalidationfailure)aremeasured.
451 Observed Outcome:ThedeliveryoftheemaildependedontheTLS/DANEstatusofthe
452 receiverandtheTLS/DANEconfigurationonthesender.Theresultswere:
453
Table C.1 Transaction Results Based on Sender TLS/DANE Connection

Receiver TLS/DANE deployment


TLS/DANE
Option TLS with valid DANE TLS with DANE PKIX TLS with DANE TLSA
No TLS
RR failure RR Error

none Mailsentin Mailsentinplaintext Mailsentinplaintext Mailsentinplaintext


plaintext

may Mailsentin Mailsentover Mailsentover Mailsentover


plaintext anonymousTLS(i.e.,no anonymousTLS(i.e.,no anonymousTLS(i.e.,no
validationofcertificate) validationofcertificate) validationofcertificate)

dane Mailsentin MailsentoverTLS(with Mailsentover Mailsentover


plaintext DANEvalidationlogged) anonymousTLS(i.e.,no anonymousTLS(i.e.,no
validationofcertificate) validationofcertificate)

dane-only Mailnot MailsentoverTLS(with Mailnotsent Mailnotsent


sent DANEvalidationlogged)

454 Fromtheabovetable,whenthesenderwasconfiguredtoneveruseTLS,themailwassentin
455 plaintextregardlessoftheTLS/DANEconfigurationofthereceiver.Whenthesenderwas
456 configuredtouseTLSopportunistically,itusedTLSregardlessofthestatusofthecertificate,or
457 TLSA.Infact,thesenderdidnotissueaquerytofindTLSARRsevenifpublished.Whenthe
458 senderusedopportunisticDANE,itusedTLSwhenavailableregardlessoftheDANEvalidations
459 results.Ifvalidationfailed,themailwasstillsentandtheresultwasloggedasanUntrustedor
460 AnonymousTLSconnection,dependingonthepresenceofaTLSARR.
461 Ofthefouroptionsusedinthelab,dane-onlywasthemostrigorousinwhatasenderwill
462 acceptbeforesendingmail.WhenthereceiverdidnotoffertheSTARTTLSoption,orlackeda
463 TLSARR,mailwasnotsent.Likewise,ifaTLSARRwaspresent,buttherewasanerrorin
464 validation(eithertheTLSARRitselfhadanerror,orPKIXfailed),themailwasnotsent.
465 Therefore,useofthisoptionwasnotrecommendedforgeneraluseasthisresultedinthe
466 majorityofemailbeingdeferred.Itshouldonlybeusedinscenarioswheresendersand
467 receiversarecoordinatedandmaintainastableDANEdeployment.

DNS-Based Email Security Practice Guide


DRAFT 89
1 Appendix D Secure Name System (DNS)
Deployment Checklist
3 ThefollowingchecklistincludesactionsrecommendedbyNISTSP800-81-2,Secure Domain
4 Name System (DNS) Deployment Guide.Thechecklistprovidessecuredeploymentguidelines
5 foreachDNScomponentbasedonpoliciesandbestpractices.Theprimarysecurity
6 specifications(withassociatedmechanisms)onwhichthechecklistisbasedareasfollows:
7 InternetEngineeringTaskForce(IETF)DomainNameSystemSecurityExtensions(DNSSEC)
8 specifications,coveredbyRequestforComments(RFC)3833,4033,4034,and4035
9 IETFTransactionSignature(TSIG)specifications,coveredbyRFCs2845and3007
10 WhilenotallofthechecklistrecommendationsapplytoallcasesofDNS-protectedemail
11 security,thechecklistisareliableguideforsecuredeploymentofDNScomponents.
12 1. Checklist item 1:Wheninstallingtheupgradedversionofnameserversoftware,the
13 administratorshouldmakenecessarychangestoconfigurationparameterstotake
14 advantageofnewsecurityfeatures.
15 2. Checklist item 2:Whetherrunningthelatestversionoranearlierversion,theadministrator
16 shouldbeawareofthevulnerabilities,exploits,securityfixes,andpatchesfortheversion
17 thatisinoperationintheenterprise.Thefollowingactionsarerecommended(forBIND
18 deployments):
19 SubscribetoISC'smailinglistcalledbind-announceornsd-usersforNSD
20 PeriodicallyrefertotheBINDvulnerabilitiespageathttp://www.isc.org/products/
21 BIND/bind-security.html
22 RefertoCERT/CC'sVulnerabilityNotesDatabaseathttp://www.kb/cert/org/vuls/and
23 theNISTNVDmetabaseathttp://nvd.nist.gov.
24 Forotherimplementations(e.g.,MSWindowsServer),otherannouncementlistsmayexist.
25 3. Checklist item 3:Topreventunauthorizeddisclosureofinformationaboutwhichversionof
26 nameserversoftwareisrunningonasystem,nameserversshouldbeconfiguredtorefuse
27 queriesforitsversioninformation.
28 4. Checklist item 4:Theauthoritativenameserversforanenterpriseshouldbebothnetwork
29 andgeographicallydispersed.Network-baseddispersionconsistsofensuringthatallname
30 serversarenotbehindasinglerouterorswitch,inasinglesubnet,orusingasingleleased
31 line.Geographicdispersionconsistsofensuringthatnotallnameserversareinthesame
32 physicallocation,andhostingatleastasinglesecondaryserveroff-site.
33 5. Checklist item 5:Ifahiddenmasterisused,thehiddenauthoritativemasterservershould
34 onlyacceptzonetransferrequestsfromthesetofsecondaryzonenameserversandrefuse
35 allotherDNSqueries.TheIPaddressofthehiddenmastershouldnotappearinthename
36 serversetinthezonedatabase.
37 6. Checklist item 6:ForsplitDNSimplementation,thereshouldbeaminimumoftwophysical
38 filesorviews.Oneshouldexclusivelyprovidenameresolutionforhostslocatedinsidethe
39 firewall.ItalsocancontainRRsetsforhostsoutsidethefirewall.Theotherfileorview

DNS-Based Email Security Practice Guide


DRAFT 89
Chapter D.

40 shouldprovidenameresolutiononlyforhostslocatedoutsidethefirewallorintheDMZ,
41 andnotforanyhostsinsidethefirewall.
42 7. Checklist item 7:Itisrecommendedthattheadministratorcreateanamedlistoftrusted
43 hosts(orblacklistedhosts)foreachofthedifferenttypesofDNStransactions.Ingeneral,
44 theroleofthefollowingcategoriesofhostsshouldbeconsideredforinclusioninthe
45 appropriateACL:
46 DMZhostsdefinedinanyofthezonesintheenterprise
47 allsecondarynameserversallowedtoinitiatezonetransfers
48 internalhostsallowedtoperformrecursivequeries
49 8. Checklist item 8:TheTSIGkey(secretstring)shouldbeaminimumof112bitsinlengthif
50 thegeneratorutilityhasbeenproventogeneratesufficientlyrandomstrings[800-57P1].
51 128bitsrecommended.
52 9. Checklist item 9:AuniqueTSIGkeyshouldbegeneratedforeachsetofhosts(i.e.aunique
53 keybetweenaprimarynameserverandeverysecondaryserverforauthenticatingzone
54 transfers).
55 10. Checklist item 10:Afterthekeystringiscopiedtothekeyfileinthenameserver,thetwo
56 filesgeneratedbythednssec-keygenprogramshouldeitherbemadeaccessibleonlytothe
57 serveradministratoraccount(e.g.,rootinUnix)or,betterstill,deleted.Thepapercopyof
58 thesefilesalsoshouldbedestroyed.
59 11. Checklist item 11:Thekeyfileshouldbesecurelytransmittedacrossthenetworktoname
60 serversthatwillbecommunicatingwiththenameserverthatgeneratedthekey.
61 12. Checklist item 12:Thestatementintheconfigurationfile(usuallyfoundat/etc/named.conf
62 forBINDrunningonUnix)thatdescribesaTSIGkey(keyname(ID),signingalgorithm,and
63 keystring)shouldnotdirectlycontainthekeystring.Whenthekeystringisfoundinthe
64 configurationfile,theriskofkeycompromiseisincreasedinsomeenvironmentswhere
65 thereisaneedtomaketheconfigurationfilereadablebypeopleotherthanthezone
66 administrator.Instead,thekeystringshouldbedefinedinaseparatekeyfileandreferenced
67 throughanincludedirectiveinthekeystatementoftheconfigurationfile.EveryTSIGkey
68 shouldhaveaseparatekeyfile.
69 13. Checklist item 13:Thekeyfileshouldbeownedbytheaccountunderwhichthename
70 serversoftwareisrun.Thepermissionbitsshouldbesetsothatthekeyfilecanbereador
71 modifiedonlybytheaccountthatrunsthenameserversoftware.
72 14. Checklist item 14:TheTSIGkeyusedtosignmessagesbetweenapairofserversshouldbe
73 specifiedintheserverstatementofbothtransactingserverstopointtoeachother.Thisis
74 necessarytoensurethatboththerequestmessageandthetransactionmessageofa
75 particulartransactionaresignedandhencesecured.
76 15. Checklist item 15:NameserversthatdeployDNSSECsignedzonesorquerysignedzones
77 shouldbeconfiguredtoperformDNSSECprocessing.
78 16. Checklist item 16:TheprivatekeyscorrespondingtoboththeZSKandtheKSKshouldnot
79 bekeptontheDNSSEC-awareprimaryauthoritativenameserverwhenthenameserver
80 doesnotsupportdynamicupdates.Ifdynamicupdateissupported,theprivatekey
81 correspondingtotheZSKaloneshouldbekeptonthenameserver,withappropriate
82 directory/file-levelaccesscontrollist-basedorcryptography-basedprotections.

DNS-Based Email Security Practice Guide


DRAFT 90
Chapter D.

83 17. Checklist item 17:SignaturegenerationusingtheKSKshouldbedoneoffline,usingtheKSK-


84 privatestoredoffline;thentheDNSKEYRRSet,alongwithitsRRSIGRR,canbeloadedinto
85 theprimaryauthoritativenameserver.
86 18. Checklist item 18:TherefreshvalueinthezoneSOARRshouldbechosenwiththe
87 frequencyofupdatesinmind.Ifthezoneissigned,therefreshvalueshouldbelessthanthe
88 RRSIGvalidityperiod.
89 19. Checklist item 19:TheretryvalueinazoneSOARRshouldbe1/10thoftherefreshvalue.
90 20. Checklist item 20:TheexpirevalueinthezoneSOARRshouldbe2to4weeks.
91 21. Checklist item 21:TheminimumTTLvalueshouldbebetween30minutesand5days.
92 22. Checklist item 22:ADNSadministratorshouldtakecarewhenincludingHINFO,RP,LOC,or
93 otherRRtypesthatcoulddivulgeinformationthatwouldbeusefultoanattacker,orthe
94 externalviewofazoneifusingsplitDNS.TheseRRtypesshouldbeavoidedifpossibleand
95 onlyusedifnecessarytosupportoperationalpolicy.
96 23. Checklist item 23:ADNSadministratorshouldreviewthedatacontainedinanyTXTRRfor
97 possibleinformationleakagebeforeaddingittothezonefile.
98 24. Checklist item 24:ThevalidityperiodfortheRRSIGscoveringazone'sDNSKEYRRSetshould
99 beintherangeof2daysto1week.Thisvaluehelpsreducethevulnerabilityperiod
100 resultingfromakeycompromise.
101 25. Checklist item 25:Azonewithdelegatedchildrenshouldhaveavalidityperiodofafew
102 daysto1weekforRRSIGscoveringtheDSRRforadelegatedchild.Thisvaluehelpsreduce
103 thechildzone'svulnerabilityperiodresultingfromaKSKcompromiseandscheduledkey
104 rollovers.
105 26. Checklist item 26:IfthezoneissignedusingNSEC3RRs,thesaltvalueshouldbechanged
106 everytimethezoneiscompletelyresigned.Thevalueofthesaltshouldberandom,andthe
107 lengthshouldbeshortenoughtopreventaFQDNtobetoolongfortheDNSprotocol(i.e.
108 under256octets).
109 27. Checklist item 27:IfthezoneissignedusingNSEC3RRs,theiterationsvalueshouldbe
110 basedonavailablecomputingpoweravailabletoclientsandattackers.Thevalueshouldbe
111 reviewedannuallyandincreasediftheevaluationconditionschange.
112 28. Checklist item 28:TTLvaluesforDNSdatashouldbesetbetween30minutes(1800
113 seconds)and24hours(86400seconds).
114 29. Checklist item 29:TTLvaluesforRRsetsshouldbesettobeafractionoftheDNSSEC
115 signaturevalidityperiodoftheRRSIGthatcoverstheRRset.
116 30. Checklist item 30:The(oftenlonger)KSKneedstoberolledoverlessfrequentlythanthe
117 ZSK.TherecommendedrolloverfrequencyfortheKSKisonceevery1to2years,whereas
118 theZSKshouldberolledoverevery1to3monthsforoperationalconsistencybutmaybe
119 usedlongerifnecessaryforstabilityorifthekeyisoftheappropriatelength.Bothkeys
120 shouldhaveanApprovedlengthaccordingtoNISTSP800-57Part1[800-57P1],[800-57P3].
121 Zones that pre-publish the new public key should observe the following:
122 31. Checklist item 31:Thesecurezonethatpre-publishesitspublickeyshoulddosoatleast
123 oneTTLperiodbeforethetimeofthekeyrollover.

DNS-Based Email Security Practice Guide


DRAFT 91
Chapter D.

124 32. Checklist item 32:Afterremovingtheoldpublickey,thezoneshouldgenerateanew


125 signature(RRSIGRR),basedontheremainingkeys(DNSKEYRRs)inthezonefile.
126 33. Checklist item 33:ADNSadministratorshouldhavetheemergencycontactinformationfor
127 theimmediateparentzonetousewhenanemergencyKSKrollovermustbeperformed.
128 34. Checklist item 34:Aparentzonemusthaveanemergencycontactmethodmadeavailable
129 toitsdelegatedchildsubzonesincaseofemergencyKSKrollover.Therealsoshouldbea
130 securemeansofobtainingthenewKSK.
131 35. Checklist item 35:Periodicre-signingshouldbescheduledbeforetheexpirationfieldofthe
132 RRSIGRRsfoundinthezone.Thisistoreducetheriskofasignedzonebeingrendered
133 bogusbecauseofexpiredsignatures.
134 36. Checklist item 36:TheserialnumberintheSOARRmustbeincrementedbeforere-signing
135 thezonefile.Ifthisoperationisnotdone,secondarynameserversmaynotpickupthenew
136 signaturesbecausetheyarerefreshedpurelyonthebasisoftheSOAserialnumber
137 mismatch.Theconsequenceisthatsomesecurity-awareresolverswillbeabletoverifythe
138 signatures(andthushaveasecureresponse)butotherscannot.
139 37. Checklist item 37:Recursiveservers/resolversshouldbeplacedbehindanorganization's
140 firewallandconfiguredtoonlyacceptqueriesfrominternalhosts(e.g.,StubResolverhost).
141 38. Checklist Item 38:WheneverAggregateCachesaredeployed,theforwardersmustbe
142 configuredtobeValidatingResolvers.
143 39. Checklist item 39:EachrecursiveservermusthavearoothintsfilecontainingtheIP
144 addressofoneormoreDNSrootservers.Theinformationintheroothintsfileshouldbe
145 periodicallycheckedforcorrectness.
146 40. Checklist item 40:Theroothintsfileshouldbeownedbytheaccountunderwhichthe
147 nameserversoftwareisrun.Thepermissionbitsshouldbesetsothattheroothintsfilecan
148 bereadormodifiedonlybytheaccountthatrunsthenameserversoftware.
149 41. Checklist item 41:Administratorsshouldconfiguretwoormorerecursiveresolversforeach
150 stubresolveronthenetwork.
151 42. Checklist item 42:EnterprisefirewallsshouldconsiderrestrictingoutboundDNStraffic
152 fromstubresolverstoonlytheenterprise'sdesignatedrecursiveresolvers.
153 43. Checklist item 43:EachrecursiveservermusthavearoothintsfilecontainingtheIP
154 addressofoneormoreDNSrootservers.Theinformationintheroothintsfileshouldbe
155 periodicallycheckedforcorrectness.
156 44. Checklist item 44:Theroothintsfileshouldbeownedbytheaccountunderwhichthe
157 nameserversoftwareisrun.Thepermissionbitsshouldbesetsothattheroothintsfilecan
158 bereadormodifiedonlybytheaccountthatrunsthenameserversoftware.
159 45. Checklist item 45:Administratorsshouldconfiguretwoormorerecursiveresolversforeach
160 stubresolveronthenetwork.
161 46. Checklist item 46:EnterprisefirewallsshouldconsiderrestrictingoutboundDNStraffic
162 fromstubresolverstoonlytheenterprise'sdesignatedrecursiveresolvers.
163 47. Checklist item 47:Non-validatingstubresolvers(bothDNSSEC-awareandnon-DNSSEC-
164 aware)musthaveatrustedlinkwithavalidatingrecursiveresolver.

DNS-Based Email Security Practice Guide


DRAFT 92
Chapter D.

165 48. Checklist item 48:Validatorsshouldroutinelyloganyvalidationfailurestoaidindiagnosing


166 networkerrors.
167 49. Checklist item 49:Mobileornomadicsystemsshouldeitherperformtheirownvalidation
168 orhaveatrustedchannelbacktoatrustedvalidator.
169 50. Checklist item 50:Mobileornomadicsystemsthatperformitsownvalidationshouldhave
170 thesameDNSSECpolicyandtrustanchorsasvalidatorsontheenterprisenetwork.
171 51. Checklist item 51:Validatoradministratormustconfigureoneormoretrustanchorsfor
172 eachvalidatorintheenterprise.
173 52. Checklist item 52:Thevalidatoradministratorregularlycheckseachtrustanchortoensure
174 thatitisstillinuse,andupdatesthetrustanchorasnecessary.
175

DNS-Based Email Security Practice Guide


DRAFT 93
1 Appendix E Overview of Products Contributed
by Collaborators
3 ComponentsprovidedbycollaboratorsincludedMailUserAgents(MUAs),MailTransferAgents
4 (MTAs),andDNSServices.MostoftheproductsincludedwereDNSservicecomponents,but
5 theseDNSservicecomponentswereinitiallyprovidedwithMUAsandMTAsinallcases.Where
6 theMUAandMTAcomponentsemployedarenotpartofthecollaborator'sstandardoffering,
7 opensourceMUAandMTAcomponentswereincludedintheinitialcollaboratorinstallation.
8 Componentoverviewsfollow:

9 E.1 Open Source MUA and MTA Components

10 E.1.1 Thunderbird Mail User Agent


11 MozillaThunderbirdisafree,opensource,cross-platformemail,news,andchatclient
12 developedbytheMozillaFoundation.Thunderbirdisanemail,newsgroup,newsfeed,andchat
13 (XMPP,IRC,Twitter)client.TheMozillaLightningextension,whichisinstalledbydefault,adds
14 PIMfunctionality.Thunderbirdcanmanagemultipleemail,newsgroup,andnewsfeed
15 accountsandsupportsmultipleidentitieswithinaccounts.Featuressuchasquicksearch,saved
16 searchfolders(virtualfolders),advancedmessagefiltering,messagegrouping,andlabelshelp
17 manageandfindmessages.OnLinux-basedsystems,systemmail(movemail)accountsare
18 supported.ThunderbirdincorporatesaBayesianspamfilter,awhitelistbasedontheincluded
19 addressbook,andcanalsounderstandclassificationsbyserver-basedfilterssuchas
20 SpamAssassin.
21 ThunderbirdhasnativesupportforRFC3851S/MIME,butRFC5757(S/MIMEversion3.2)isnot
22 supported.Supportforothersecuritysystemscanbeaddedbyinstallingextensions(e.g,the
23 EnigmailextensionaddssupportforPGP).S/MIMEandPGPcannotbothbeusedinthesame
24 message.SSL/TLSisalsosupported,butitisusedonlytotemporarilyencryptdatabeingsend
25 andreceivedbetweenanemailclientandserver.SSL/TLScanworkincombinationwithS/
26 MIMEorOpenPGP.
27 ThunderbirdsupportsPOPandIMAP.ItalsosupportsLDAPaddresscompletion.Thunderbird
28 supportstheS/MIMEstandard,extensionssuchasEnigmailaddsupportfortheOpenPGP
29 standard.AlistofsupportedIMAPextensionscanbefoundatwiki.mozilla.org.Sinceversion
30 38,Thunderbirdhasintegratedsupportforautomaticlinkingoflargefilesinsteadofattaching
31 themdirectlytothemailmessage.
32 Thunderbirdrunsonavarietyofplatforms.Releasesavailableontheprimarydistributionsite
33 supportLinux,Windows,andOSXoperatingsystems.UnofficialportsareavailableforFreeBSD,
34 OpenBSD,OpenSolaris,OS/2,andeComStation.

35 E.1.2 Dovecot
36 DovecotisusedintheDNS-BasedEmailSecurityprojecttopermitMUAaccesstothePostfix
37 MTA.DovecotisanopensourceIMAP1andPOP3emailserverforLinux/UNIX-likesystems,

DNS-Based Email Security Practice Guide


DRAFT 94
Chapter E.

38 writtenwithsecurityprimarilyinmind.Dovecotisusedinbothsmallandlargeinstallations.It
39 iscompactandrequiresnospecialadministrationanditusesverylittlememory.Dovecot
40 supportsthestandardmboxandMaildirformats.Themailboxesaretransparentlyindexedand
41 providefullcompatibilitywithexistingmailboxhandlingtools.Dovecotv1.1passesallIMAP
42 serverstandardcompliancetests.Dovecotallowsmailboxesandtheirindexestobemodified
43 bymultiplecomputersatthesametime,providingcompatibilitywithclusteredfilesystems.
44 Cachingproblemscanbeworkedaroundwithdirectorproxies.Postfix2.3+andExim4.64+
45 userscandoSMTPauthenticationdirectlyagainstDovecot'sauthenticationbackendwithout
46 havingtoconfigureitseparately,andDovecotsupportseasymigrationfrommanyexisting
47 IMAPandPOP3servers,allowingthechangetobetransparenttoexistingusers.
48 DovecotcurrentlyoffersIMAP4rev1,POP3,IPv6,SSLandTLSsupport.Itsupportsmultiple
49 commonlyusedIMAPextensions,includingSORT,THREADandIDLE.Sharedmailboxesare
50 supportedinv1.2+.Maildir++quotaissupported,buthardfilesystemquotacanintroduce
51 problems.DovecotiscommonlyusedwithLinux,Solaris,FreeBSD,OpenBSD,NetBSDandMac
52 OSX.SeetheDovecotWikipage(http://wiki2.dovecot.org/OSCompatibility)aboutOS
53 compatibilityformore.

54 E.1.3 Postfix
55 Postfixisafreeandopen-sourcemailtransferagent(MTA)thatroutesanddeliverselectronic
56 mail.PostfixisreleasedundertheIBMPublicLicense1.0whichisafreesoftwarelicense.Asan
57 SMTPclient,Postfiximplementsahigh-performanceparallelizedmail-deliveryengine.Postfixis
58 oftencombinedwithmailing-listsoftware(suchasMailman).
59 Postfixconsistsofacombinationofserverprogramsthatruninthebackground,andclient
60 programsthatareinvokedbyuserprogramsorbysystemadministrators.ThePostfixcore
61 consistsofseveraldozenserverprogramsthatruninthebackground,eachhandlingone
62 specificaspectofemaildelivery.ExamplesaretheSMTPserver,thescheduler,theaddress
63 rewriter,andthelocaldeliveryserver.Fordamage-controlpurposes,mostserverprogramsrun
64 withfixedreducedprivileges,andterminatevoluntarilyafterprocessingalimitednumberof
65 requests.Toconservesystemresources,mostserverprogramsterminatewhentheybecome
66 idle.
67 ClientprogramsrunoutsidethePostfixcore.TheyinteractwithPostfixserverprograms
68 throughmaildeliveryinstructionsintheuser's~/.forwardfile,andthroughsmallgate
69 programstosubmitmailortorequestqueuestatusinformation.
70 AsanSMTPserver,Postfiximplementsafirstlayerofdefenseagainstspambotsandmalware.
71 AdministratorscancombinePostfixwithothersoftwarethatprovidesspam/virusfiltering(e.g.,
72 Amavisd-new),message-storeaccess(e.g.,Dovecot),orcomplexSMTP-levelaccess-policies
73 (e.g.,postfwd,policyd-weightorgreylisting).

1.TheInternetMessageAccessProtocol(IMAP)isamailprotocolusedforaccessingemailona
remotewebserverfromalocalclient.IMAPandPOP3arethetwomostcommonlyusedInternet
mailprotocolsforretrievingemails.Bothprotocolsaresupportedbyallmodernemailclients
andwebservers.

DNS-Based Email Security Practice Guide


DRAFT 95
Chapter E.

74 Featuresinclude:
75 standards-compliantsupportforSMTPUTF8,SMTP,LMTP,STARTTLSencryptionincluding
76 DANEprotocolsupportandperfectforwardsecrecy,SASLauthentication,MIME
77 encapsulationandtransformation,DSNdeliverystatusnotifications,IPv4,andIPv6
78 configurableSMTP-levelaccesspolicythatautomaticallyadaptstooverload
79 virtualdomainswithdistinctaddress-namespaces
80 UNIX-systeminterfacesforcommand-linesubmission,fordeliverytocommand,andfor
81 directdeliverytomessagestoresinmboxandmaildirformat
82 light-weightcontentinspectionbasedonregularexpressions
83 databaselookupmechanismsincludingBerkeleyDB,CDB,OpenLDAPLMDB,Memcached,
84 LDAPandmultipleSQLdatabaseimplementations
85 aschedulerthatimplementsparalleldeliveries,withconfigurableconcurrencyandback-off
86 strategies
87 ascalablezombieblockerthatreducesSMTPserverloadduetobotnetspam
88 PostfixextensionsusetheSMTPorMilter(Sendmailmailfilter)protocolswhichbothgivefull
89 controloverthemessageenvelopeandcontent,orasimpletext-basedprotocolthatenables
90 complexSMTP-levelaccesscontrolpolicies.Extensionsinclude:
91 deepcontentinspectionbeforeorafteramessageisacceptedintothemailqueue
92 mailauthenticationwithDMARC,DKIM,SPF,orotherprotocols
93 SMTP-levelaccesspoliciessuchasgreylistingorratecontrol
94 PostfixrunsonBSD,GNU/Linux,OSX,SolarisandmostotherUnix-likeoperatingsystem,
95 generallyshipswithaCcompiler,anddeliversastandardPOSIXdevelopmentenvironment.Itis
96 thedefaultMTAfortheOSX,NetBSDandUbuntuoperatingsystems.

97 E.2 Microsoft Windows-Based Components


98 Microsoft'scontributionincludesacompleteMUA,MTA,andDNSservicestack,thougheachof
99 thecomponentscanbeintegratedintosystemsprovidedbyothercontributors.

100 E.2.1 Outlook


101 MicrosoftOutlookisapersonalinformationmanagerfromMicrosoft,availableasapartofthe
102 MicrosoftOfficesuite.Althoughoftenusedmainlyasanemailapplication,italsoincludesa
103 calendar,taskmanager,contactmanager,notetaking,journal,andwebbrowsing.Itcanbe
104 usedasastand-aloneapplication,orcanworkwithMicrosoftExchangeServerandMicrosoft
105 SharePointServerformultipleusersinanorganization,suchassharedmailboxesand
106 calendars,Exchangepublicfolders,SharePointlists,andmeetingschedules.Microsofthasalso
107 releasedmobileapplicationsformostmobileplatforms,includingiOSandAndroid.Developers
108 canalsocreatetheirowncustomsoftwarethatworkswithOutlookandOfficecomponents
109 usingMicrosoftVisualStudio.Inaddition,mobiledevicescansynchronizealmostallOutlook
110 datatoOutlookMobile.MicrosoftOutlookmailsystemusestheproprietaryMessaging

DNS-Based Email Security Practice Guide


DRAFT 96
Chapter E.

111 ApplicationProgrammingInterface(MAPI)toaccessMicrosoftExchangeelectronicmail
112 servers.
113 OutlooksupportsS/MIME(Secure/MultipurposeInternetMailExtensions)isastandardfor
114 publickeyencryptionandsigningofMIMEdata.S/MIMEisonanIETFstandardstrackand
115 definedinanumberofdocuments,mostimportantlyRFCs3369,3370,3850and3851.

116 E.2.2 Exchange


117 MicrosoftExchangeServerisacalendaringandmailserverdevelopedbyMicrosoftthatruns
118 exclusivelyontheMicrosoftWindowsServerproductline.ExchangeServerwasinitially
119 Microsoft'sinternalmailserverbutisnowpublishedoutsideMicrosoft.ItusestheActive
120 Directorydirectoryservice.ItisbundledwiththeOutlookemailclient.
121 ExchangeServersupportsPOP3,IMAP,SMTPandEAS.ItalsosupportsIPv6,SMTPoverTLS,PoP
122 overTLS,NNTP,andSSL.ExchangeServerislicensedbothintheformsofon-premisessoftware
123 andsoftwareasaservice.Intheon-premisesform,customerpurchaseclientaccesslicenses
124 (CALs).Inthesoftwareasaserviceform,Microsoftreceivesamonthlyservicefeeinstead(see
125 https://en.wikipedia.org/wiki/Office_365).

126 E.2.3 Server DNS Services


127 WindowsServer2016isaserveroperatingsystemdevelopedbyMicrosoftaspartofthe
128 WindowsNTfamilyofoperatingsystems,developedconcurrentlywithWindows10.Microsoft
129 Serverfeaturesservervirtualization,networking,servermanagementandautomation,aweb
130 andapplicationplatform,accessandinformationprotection,andvirtualdesktopinfrastructure.
131 KeyoperatingsystemelementsfortheDNS-BasedEmailSecurityprojectareActiveDirectory
132 andDNSServer.

133 E.2.3.1 Active Directory


134 ActiveDirectory(AD)isadirectoryservicethatMicrosoftdevelopedforWindowsdomain
135 networks.ItisincludedinmostWindowsServeroperatingsystemsasasetofprocessesand
136 services.Initially,ActiveDirectorywasonlyinchargeofcentralizeddomainmanagement.
137 ActiveDirectoryisanumbrellatitleforabroadrangeofdirectory-basedidentity-related
138 services.AserverrunningActiveDirectoryDomainServices(ADDS)iscalledadomain
139 controller.ItauthenticatesandauthorizesallusersandcomputersinaWindowsdomaintype
140 network-assigningandenforcingsecuritypoliciesforallcomputersandinstallingorupdating
141 software.Forexample,whenauserlogsintoacomputerthatispartofaWindowsdomain,
142 ActiveDirectorychecksthesubmittedpasswordanddetermineswhethertheuserisasystem
143 administratorornormaluser.
144 ActiveDirectoryusesLightweightDirectoryAccessProtocol(LDAP)versions2and3,Microsoft's
145 versionofKerberos,andDNS.ActiveDirectoryDomainServices(ADDS)isthecornerstoneof
146 everyWindowsdomainnetwork.Itstoresinformationaboutmembersofthedomain,including
147 devicesandusers,verifiestheircredentialsanddefinestheiraccessrights.Theserver(orthe
148 clusterofservers)runningthisserviceiscalledadomaincontroller.Adomaincontrolleris
149 contactedwhenauserlogsintoadevice,accessesanotherdeviceacrossthenetwork,orrunsa
150 line-of-businessMetro-styleapplicationsideloadedintoadevice.OtherActiveDirectory
151 services(excludingLDS,aswellasmostofMicrosoftservertechnologiesrelyonoruseDomain

DNS-Based Email Security Practice Guide


DRAFT 97
Chapter E.

152 Services;examplesincludeGroupPolicy,EncryptingFileSystem,BitLocker,DomainName
153 Services,RemoteDesktopServices,ExchangeServerandSharePointServer.
154 ActiveDirectoryCertificateServices(ADCS)establishesanon-premisespublickey
155 infrastructure.Itcancreate,validateandrevokepublickeycertificatesforinternalusesofan
156 organization.Thesecertificatescanbeusedtoencryptfiles(whenusedwithEncryptingFile
157 System),emails(perS/MIMEstandard),networktraffic(whenusedbyvirtualprivatenetworks,
158 TransportLayerSecurityprotocolorIPSecprotocol).

159 E.2.3.2 DNS Server


160 MicrosoftWindowsserveroperatingsystemscanruntheDNSServerservice,amonolithicDNS
161 serverthatprovidesmanytypesofDNSservice,includingcaching,DynamicDNSupdate,zone
162 transfer,andDNSnotification.DNSnotificationimplementsapushmechanismfornotifyinga
163 selectsetofsecondaryserversforazonewhenitisupdated.DNSServerhasimproved
164 interoperabilitywithBINDandotherimplementationsintermsofzonefileformat,zone
165 transfer,andotherDNSprotocoldetails.
166 Microsoft'sDNSserversupportsdifferentdatabasebackends.Microsoft'sDNSserversupports
167 twosuchbackends.DNSdatacanbestoredeitherinmasterfiles(alsoknownaszonefiles)or
168 intheActiveDirectorydatabaseitself.Inthelattercase,sinceActiveDirectory(ratherthanthe
169 DNSserver)handlestheactualreplicationofthedatabaseacrossmultiplemachines,the
170 databasecanbemodifiedonanyserver(multiple-masterreplication),andtheadditionor
171 removalofazonewillbeimmediatelypropagatedtoallotherDNSserverswithinthe
172 appropriateActiveDirectoryreplicationscope.(ContrastthiswithBIND,wherewhensuch
173 changesaremade,thelistofzones,inthe/etc/named.conffile,hastobeexplicitlyupdatedon
174 eachindividualserver.)
175 Microsoft'sDNSservercanbeadministeredusingeitheragraphicaluserinterface,theDNS
176 ManagementConsole,oracommandlineinterface,thednscmdutility.NewtoWindows
177 Server2012isafullyfeaturedPowerShellproviderforDNSservermanagement.

178 E.3 NLnet Labs Name Server Daemon-Based


179 Components

180 E.3.1 NSD4 Authoritative Name Server


181 NameServerDaemon(NSD)isanopen-sourceDNSserver.Itwasdevelopedfromscratchby
182 NLnetLabsofAmsterdamincooperationwiththeRIPENCC,asanauthoritativenameserver
183 (i.e.,notimplementingtherecursivecachingfunctionbydesign).Theintentionofthis
184 developmentistoaddvariancetothegenepoolofDNSimplementationsoriginallyintended
185 forrootservers,top-leveldomains(TLDs)andsecond-leveldomains(SLDs),thusincreasingthe
186 resilienceofDNSagainstsoftwareflawsorexploits.
187 NSDusesBIND-stylezone-files(zone-filesusedunderBINDcanusuallybeusedunmodifiedin
188 NSD,onceenteredintotheNSDconfiguration).
189 Thecollectionofprograms/processesthatmake-upNSDaredesignedsothattheNSDdaemon
190 itselfrunsasanon-privilegeduserandcanbeeasilyconfiguredtoruninaChrootjail,suchthat

DNS-Based Email Security Practice Guide


DRAFT 98
Chapter E.

191 securityflawsintheNSDdaemonarenotsolikelytoresultinsystem-widecompromiseas
192 withoutsuchmeasures.
193 ThelatestcurrentstablereleaseisNSD4.1.13.Downloadthelatestversionhere:https://
194 www.nlnetlabs.nl/downloads/nsd/nsd-4.1.10.tar.gz.
195 NSDisthoroughlytested,thereisaregressiontestsreportavailable.
196 ForNSD4,thememoryestimationtoolcanbecompiledinthesourcetarballwithmake nsd-
197 memandrunningitonaconfigfilewiththezonefilesinquestion.

198 NLnetLabshasalong-termcommitmentforsupportingNSD.Therewillbeanadvancednotice
199 whentheorganization'scommitmentends.ThelatestNSDreleasewillsupportedforatleast
200 twoyearsafteranend-of-lifenotificationhasbeensenttothecommunity.
201 Manualpagesareinstalled,theycanalsobeviewed:
202 1. nsd(8)manpage:https://www.nlnetlabs.nl/projects/nsd/nsd.8.html
203 2. nsd-control(8)manpage:https://www.nlnetlabs.nl/projects/nsd/nsd-control.8.html
204 3. nsd-checkconf(8)manpage:https://www.nlnetlabs.nl/projects/nsd/nsd-checkconf.8.html
205 4. nsd-checkzone(8)manpage:https://www.nlnetlabs.nl/projects/nsd/nsd-checkzone.8.html
206 5. nsd.conf(5)manpage:https://www.nlnetlabs.nl/projects/nsd/nsd.conf.5.html
207 NSDuserscansubscribetonsd-usersandbrowsethearchivesofnsd-usersherehttp://
208 open.nlnetlabs.nl/mailman/listinfo/nsd-users/.
209 TherepositoryofNSDisavailableat/svn/nsd/,theNSD4.x.xdevelopmenttreeislocatedin
210 trunk/.

211 E.3.2 OpenDNSSEC Domain Name Security Manager


212 OpenDNSSECsoftwaremanagesthesecurityofdomainnamesontheInternet.The
213 OpenDNSSECprojectisacooperativeeffortintendedtodriveadoptionofDomainName
214 SystemSecurityExtensions(DNSSEC)inordertofurtherenhanceInternetsecurity.
215 OpenDNSSECwascreatedasanopen-sourceturn-keysolutionforDNSSEC.ItsecuresDNSzone
216 datajustbeforeitispublishedinanauthoritativenameserver.OpenDNSSECtakesinunsigned
217 zones,addsdigitalsignaturesandotherrecordsforDNSSECandpassesitontothe
218 authoritativenameserversforthatzone.OpenDNSSECwillfurthermoretakecareofthekey
219 managementandroll-overproceduretoreplacekeys.Itactsasabumpinthewire,whereit
220 willfitinanexistingDNStoolchainwithoutmodificationinthattoolchain.Incrementally
221 incorporatingchangesandre-usingalreadysignedzonestoperformaconstantup-to-date
222 zone.
223 AllkeysarestoredinahardwaresecuritymoduleandaccessedviaPKCS#11,astandard
224 softwareinterfaceforcommunicatingwithdeviceswhichholdcryptographicinformationand
225 performcryptographicfunctions.OpenDNSSECusesSoftHSM,OpenSSL,theBotan
226 cryptographiclibrary,andSQLiteorMySQLasdatabaseback-end.Itisusedonthe.se,.dk,.nl
227 .ca,.za,.uk,andothertop-leveldomains.OpenDNSSECcanbedownloadedfrom:
228 https://dist.opendnssec.org/source/opendnssec-2.0.1.tar.gz
229 https://dist.opendnssec.org/source/opendnssec-2.0.1.tar.gz.sig

DNS-Based Email Security Practice Guide


DRAFT 99
Chapter E.

230 ChecksumSHA256:
231 bf874bbb346699a5b539699f90a54e0c15fff0574df7a3c118abb30938b7b346
232 InAugustof2014,NLnetLabstookresponsibilityforcontinuingtheOpenDNSSECactivitiesof
233 boththeOpenDNSSECsoftwareprojectandtheSwedishOpenDNSSECAB.

234 E.3.3 Unbound DNS Resolver


235 Unboundisavalidating,recursive,andcachingDNSresolver.TheCimplementationof
236 UnboundisdevelopedandmaintainedbyNLnetLabs.Itisbasedonideasandalgorithmstaken
237 fromaJavaprototypedevelopedbyVerisignlabs,Nominet,Kireiandep.net.Unboundis
238 designedasasetofmodularcomponents,sothatalsoDNSSEC(secureDNS)validationand
239 stub-resolvers(thatdonotrunasaserver,butarelinkedintoanapplication)areeasilypossible.
240 ThesourcecodeisunderaBSDLicense.
241 Release1.5.9ofUnboundwasreleasedJune9,2016.Therepositoryforunboundisavailable
242 https://unbound.nlnetlabs.nl/svn/.Thedevelopmenttreeislocatedintrunk/.
243 Thelatestsourcecodetarballisavailablefordownload.
244 UnboundproblemscanbereportedthroughtheNLnetLabsbugzillawebinterface.Inthecase
245 NLnetLabswillstopsupportingtheproduct,andtheywillannouncesuchtwoyearsinadvance.
246 UnboundissubjecttoNLnetLabsSecurityPatchPolicy.CommercialsupportforUnboundis
247 availablefromseveralorganizations.

248 E.4 ISC BIND Component


249 InternetSystemsConsortium,Inc.,alsoknownasISC,isanon-profitcorporationthatsupports
250 theinfrastructureoftheInternetbydevelopingandmaintainingcoreproduction-quality
251 software,protocols,andoperations.ISChasdevelopedseveralkeyInternettechnologiesthat
252 enabletheglobalInternet,includingBIND.
253 BINDisopensourcesoftwarethatimplementstheDomainNameSystem(DNS)protocolsfor
254 theInternet.Itisareferenceimplementationofthoseprotocols,butitisalsoproduction-grade
255 software,suitableforuseinhigh-volumeandhigh-reliabilityapplications.TheacronymBIND
256 standsforBerkeleyInternetNameDomain,becausethesoftwareoriginatedintheearly1980s
257 attheUniversityofCaliforniaatBerkeley.
258 BINDiswidelyusedDNSsoftwarethatprovidesastableplatformontopofwhichorganizations
259 canbuilddistributedcomputingsystemsthatarefullycompliantwithpublishedDNSstandards.
260 BINDistransparentopensource.Ifanorganizationneedssomefunctionalitythatisnotin
261 BIND,itispossibletomodifyit,andcontributethenewfeaturebacktothecommunityby
262 sendingISCitssource.ItispossibletodownloadatarballfromtheISCwebsite(https://
263 www.isc.org/downloads/),ftp.isc.org(http://ftp.isc.org/isc/bind9/cur/),orabinaryfroman
264 organization'soperatingsystemrepository.
265 TheBINDsoftwaredistributionhasthreeparts:

DNS-Based Email Security Practice Guide


DRAFT 100
Chapter E.

266 E.4.1 Domain Name Resolver


267 TheBINDresolverisaprogramthatresolvesquestionsaboutnamesbysendingthose
268 questionstoappropriateserversandrespondingappropriatelytotheservers'replies.Inthe
269 mostcommonapplication,awebbrowserusesalocalstubresolverlibraryonthesame
270 computertolookupnamesintheDNS.Thatstubresolverispartoftheoperatingsystem.
271 (ManyoperatingsystemdistributionsusetheBINDresolverlibrary.)Thestubresolverusually
272 willforwardqueriestoacachingresolver,aserverorgroupofserversonthenetwork
273 dedicatedtoDNSservices.Thoseresolverswillsendqueriestooneormultipleauthoritative
274 serversinordertofindtheIPaddressforthatDNSname.
275 DNSauthoritativeoperationsincludethefollowingfeatures:
276 1. NXDOMAIN Redirect:Whenausersearchesforanon-existentdomain,(NXDOMAIN
277 response)theusercanberedirectedtoanotherwebpage.ThisisdoneusingtheBINDDLZ
278 feature.
279 2. Flexible Cache Controls:Fromtimetotimeuserscangetincorrectoroutdatedrecordsin
280 theresolvercache.BINDgivesuserstheabilitytoremovethemselectivelyorwholesale.
281 3. Split DNS:BINDprovidestheabilitytoconfiguredifferentviewsinasingleBINDserver.This
282 allowsuserstogiveinternal(on-network)andexternal(fromtheInternet)usersdifferent
283 viewsofDNSdata,keepingsomeDNSinformationprivate.
284 4. Cache Hit Rate Optimization:BINDisdesignedtobepersistentandresilientinresolving
285 queriesevenwhenthereisadelayinresponding,inordertopopulatethecacheforlater
286 requests.DNSPre-fetchisatechniqueforcontinuouslyrefreshingthecachedrecordsfor
287 populardomains,reducingthetimetheuserhastowaitforaresponse.
288 5. Resolver Rate-limiting:BeginningwithBIND9.10.3,twonewconfigurationparameters
289 wereadded,fetches-per-zoneandfetches-per-server.Thesefeaturesenablerate-limiting
290 queriestoauthoritativesystemsthatappeartobeunderattack.Thesefeatureshavebeen
291 successfulinmitigatingtheimpactofaDDOSattackonresolversinthepathoftheattack.
292 6. DNSSEC Validation:DNSSECvalidationprotectsclientsfromimpostorsites.InBIND,thisis
293 enabledwithasinglecommand.BINDsupportsRFC5011maintenanceofrootkeytrust
294 anchors.BINDalsohasaNegativeTrustAnchorfeature(introducedinthe9.9subscription
295 branch),whichtemporarilydisablesDNSSECvalidationwhenthereisaproblemwiththe
296 authoritativeserver'sDNSSECsupport.
297 7. Geo IP:GeoIP,orGeographicIP,allowsaBINDDNSservertoprovidedifferentresponses
298 basedonthenetworkinformationabouttherecursiveDNSresolverthatauserisusing.
299 ThereisanactiveInternetDraftdescribinganothermechanismforprovidinglocation
300 information,calledEDNS-Client-Subnet-Identifier.Thisrequirestheresolvertocache
301 multipledifferentaddressesforagivenDNSrecord,dependingontheaddressofthe
302 requester.ThisfeaturehasnotbeenaddedtotheBIND9resolver,althoughthe
303 correspondingfeaturehasbeendevelopedfortheBIND9authoritativeserver.
304 8. Response Policy Zone:AResponsePolicyZoneorRPZisaspecially-constructedzonethat
305 specifiesapolicyruleset.Theprimaryapplicationisforblockingaccesstozonesthatare
306 believedtobepublishedforabusiveorillegalpurposes.Therearecompanieswho
307 specializeinidentifyingabusesitesontheInternet,whomarkettheselistsintheformof
308 RPZfeeds.FormoreinformationonRPZ,includingalistofDNSreputationfeedproviders,
309 seehttps://dnsrpz.info.

DNS-Based Email Security Practice Guide


DRAFT 101
Chapter E.

310 E.4.2 Domain Name Authority Server


311 TheauthoritativeDNSserveranswersrequestsfromresolvers,usinginformationaboutthe
312 domainnamesitisauthoritativefor.EnterprisescanprovideDNSservicesontheInternetby
313 installingthissoftwareonaserverandgivingitinformationabouttheenterprise'sdomain
314 names.
315 1. Response Rate Limiting:AnenhancementtotheDNSprotocoltoreducetheproblemof
316 amplificationattacksbylimitingDNSresponses.Responseratelimitingisonbydefault.
317 2. Dynamically-Loadable Zones:enableBIND9toretrievezonedatadirectlyfromanexternal
318 database.Thisisnotrecommendedforhigh-queryrateauthoritativeenvironments.
319 3. Reload Time Reduction:BINDserverzonefilescanbeupdatedviansupdate,and'dynamic'
320 zonefilescanbeaddedviaRNDC,bothwithoutrestartingBIND.Forthosetimeswhenitis
321 necessarytorestart,theMAPzonefileformatcanspeedupre-loadingalargezonefileinto
322 BIND,suchasonrestart.
323 4. Hardware Security Modules:BINDsupportstheuseofHardwareSecurityModulesthrough
324 eitheranativePKCS#11interface,ortheOpenSSLPKCS#11provider.HSMsareusedto
325 storekeymaterialoutsideofBINDforsecurityreasons.
326 5. DNSSEC With In-line Signing: BINDfullysupportsDNSSECWithIn-lineSigningandhasan
327 easy-touseimplementation.Onceanenterprisehasinitiallysigneditszones,BINDcan
328 automaticallyre-signtherecordsastheyareupdatedwithin-linesigning,maintainingthe
329 DNSSECvalidityoftherecords.BINDsupportsbothNSECandNSEC3andinlinesigning
330 workswithNSEC3.
331 6. Catalog Zones:CatalogZoneswereintroducedinBIND9.11.0tofacilitatetheprovisioning
332 ofzoneinformationacrossanameserverconstellation.CatalogZonesareparticularlyuseful
333 whentherearealargenumberofsecondaryservers.Aspecialzoneofanewtype,acatalog
334 zone,issetuponthemaster.Onceacatalogzoneisconfigured,whenanoperatorwishesto
335 addanewzonetothenameserverconstellations/hecanprovisionthezoneinoneplace
336 only,onthemasterserverandaddanentrydescribingthezonetothecatalogzone.Asthe
337 secondaryserversreceivetheupdatedcopyofthecatalogzonedatatheywillnotethenew
338 entryandautomaticallycreateazoneforit.Deletionofazonelistedinacatalogzoneis
339 donebydeletingtheentryinthecatalogzoneonthemaster.
340 7. Scalable Master/Slave Hierarchy:ADNSauthoritativesystemiscomposedofazone
341 primaryormasterwithoneormoreslaveservers.Zonesfilesareestablishedandupdated
342 onamasterBINDserver.Slavesmaintaincopiesofthezonefilesandanswerqueries.This
343 configurationallowsscalingtheanswercapacitybyaddingmoreslaves,whilezone
344 informationismaintainedinonlyoneplace.Themastersignalsthatupdatedinformationis
345 availablewithanotifymessagetotheslaves,andtheslavestheninitiateanupdatefrom
346 themaster.BINDfullysupportsboththeAXFR(completetransfer)andIXFR(incremental
347 transfer)methods,usingthestandardTSIGsecuritymechanismbetweenservers.Thereare
348 anumberofconfigurationoptionsforcontrollingthezoneupdatingprocess.

349 E.4.3 Tools


350 ISCincludesanumberofdiagnosticandoperationaltools.Someofthem,suchasthepopular
351 DIGtool,arenotspecifictoBINDandcanbeusedwithanyDNSserver.

DNS-Based Email Security Practice Guide


DRAFT 102
Chapter E.

352 E.5 Secure64 Component


353 TheSecure64contributionsincludedanautomatedonlineSecure64DNSSignerdeliveredon
354 dedicatedhardwareandDNSSEC-capableVMimagesofDNSCache,DNSAuthority,andDNS
355 Manager.DNSManagerprovidedcentralizedmanagementofSecure64DNSCachesoftware
356 andconfigurationsandprovidednetwork-widemonitoringofkeyperformanceindicators.DNS
357 Managerallowedcreationofgroupsofserversandassignmentofconfigurationstoagroup,a
358 singleserver,orallservers.DNSAuthorityisanauthoritativesignerandserverasasingle
359 platform.ThisstackwasabletodemonstrateOutlook,Thunderbird,orAppleMailasMUAsand
360 usesPostfixasanMTAandDovecottoprovideIMAPforclients.DescriptionsoftheDNSservice
361 componentsfollow:

362 E.5.1 DNS Signer


363 Secure64DNSSignerisDNSSECkeymanagementandzonesigningsoftwarethatisdesignedto
364 facilitateandprovidesecurityforDNSSECimplementation.Secure64DNSSignerfully
365 automatesDNSSECkeygeneration,keyrollover,zonesigningandre-signingprocesses,Itis
366 designedtoscaletolarge,dynamicenvironmentsbymaintainingDNSSECsigningkeyssecurely
367 onlinewhileprovidingincrementalzonesigningandhighsigningperformance.Signer
368 integratesintoexistinginfrastructuresconfigurations.ItisfullycompatiblewithSecure64DNS
369 Authority,BIND,NSD,andMicrosoftDNSmastersandslaves.SignersupportsalloftheRFCs
370 andbestpracticesrequiredtodeployDNSSEC.

371 E.5.2 DNS Authority


372 Secure64DNSAuthorityisanameserversoftwareproduct.Itprovidesbuilt-inDoSprotection
373 thatidentifiesandblocksTCPorUDPattacktraffic.Itisdesignedtorespondtolegitimate
374 queries,evenwhileunderattack.DNSAuthorityprovidesreal-timealertsandattack
375 characteristicsthroughsyslogandSNMPtrapsinordertoenableremedialaction.Authorityis
376 alsodesignedtobeanycastedinanydatacenter,evenforenterprisesthatdon'toperatethe
377 routinginfrastructure.Theadministratorcaninsertandwithdrawserverswithoutrequiring
378 routerchangesordeployingdedicatedrouterhardware.AuthoritydirectlyreadsexistingBIND
379 configurationfilesandisinteroperablewithnameserversrunningBIND,NSD,orMicrosoft
380 WindowsDNSsoftware.Somespecificfeaturesincludethefollowing:
381 1. IPv6 support:AuthoritysupportsIPv6ineitherdualstackorIPv6-onlymode.
382 2. PipeProtector:Authority'sPipeProtectorTMfeatureprotectsnetworksbyautomatically
383 identifyingthesourcesofamplifiedfloodattacksandcommunicatingwiththeupstream
384 routertoblackholetheattacktraffic.
385 3. Built-in BGP:Built-inBorderGatewayProtocol(BGP)permitsAuthoritytobesetupinan
386 anycastconfiguration,whichprovidesgreaterresiliencyagainstdenial-of-serviceattacks
387 andimprovedperformance.AfterBGPisinitiallyconfigured,theadministratorcaninsert
388 andwithdrawtheserverfromtheanycastclusterwithoutmakingrouterchanges.
389 4. Secured runtime environment:AuthorityisdesignedtorunonaSourceToperatingsystem
390 andtoutilizesserverhardwaresecuritycapabilitiestoeliminateallpathsforinjectionor
391 executionofmaliciouscodeatruntime.

DNS-Based Email Security Practice Guide


DRAFT 103
Chapter E.

392 5. System Authentication: Digitalsignaturesofthefirmware,operatingsystemand


393 applicationcodeareallvalidatedduringthebootprocess.Thisprotectsagainstthe
394 operatingsystemandtheapplicationcodeimagesondiskfrombeingcompromisedbya
395 rootkit.
396 6. Secured zone data:Authorityprovidesend-to-endintegrityprotectionofzonedataby
397 supportingDNSSEC,TSIGandACLsforqueries,notifiesandzonetransfers.
398 7. Synthesized PTR records:ReverseDNSrecordsforIPv6addressesorotherlargeaddress
399 blockscanbegeneratedontheflywherenecessarytopreservecompatibilitywithother
400 systemsthatrelyupontheexistenceofthesereverserecords.
401 8. Standards support:AuthoritysupportsENUMstandards,includingRFC3163(SIPinitiation
402 protocol),RFC6116(storageofdataforE.164numbersintheDNS)and3GPPTS29.303
403 (DNSproceduresfortheEvolvedPacketSystem).
404 9. Split horizon DNS:Viewspermitconfigurationofanauthoritativeservertoprovide
405 differentfunctionalityandresponsesbasedoncharacteristicsoftherequestingclient.

406 E.5.3 DNS Cache


407 Secure64DNSCacheisscalable,secure,cachingDNSsoftwaredesignedtoprovidebuilt-in
408 protectionagainsthighvolumedenial-of-serviceattacksandimmunitytoBIND-specificsecurity
409 vulnerabilities.DNSGuardisafamilyofsecurityservicesthatprotectusersandthenetwork
410 frommaliciousactivity,whiletheWebErrorRedirectionModuleallowsserviceprovidersto
411 improvetheenduser'sexperiencewhilegeneratingincrementalrevenuesthatflowrighttothe
412 bottomline.Somespecificfeaturesincludethefollowing:
413 1. IPv6 Support:DNSCachesupportsbothdualstackanddeploymentofapureIPv6network
414 whileprovidingcompatibilitywithIPv4networks.
415 2. Built-In DDoS Protection:Built-inDDoSdetectionandmitigationallowsDNSCacheto
416 continuetorespondtolegitimatequerieswhilefendingoffhighvolumedenial-of-service-
417 attacks.ThiscombatsacommonissuewithDNSsolutionsthatcrashorbecomeunavailable
418 atlowerlevelsofattacktraffic.Inadditiontomitigatinghighvolumeattacks,DNSCache
419 automaticallydetectscasesofindividualclientsexceedingauser-definedquerythreshold
420 andtemporarilyblackliststhemwhilelogginginformationabouttheoffendingclient.This
421 helpspreventinadvertentparticipationinadenial-of-serviceattack.
422 3. SNMP:DNSCacheprovidesseveralMIBs,thatallowmonitoringofthechassis,network,
423 operatingsystemandapplicationinrealtimeandsupportavarietyofnetworkmonitoring
424 systems.Inaddition,DNSCachedirectlyprovidesalertsofcriticaloperationalconditions
425 throughSNMPtrapswithoutrequiringspecialconfigurationwithinthenetworkmonitoring
426 system.
427 4. Centralized management: DNSCacheserverscanbemanagedindividually,orcanbe
428 centrallymanagedandmonitoredthroughSecure64DNSManager.
429 5. Scalable performance:Ata90%cachehitrate,DNSCachedeliversover125,000queries
430 persecond,whichcaneasilybeincreasedto280,000queriespersecondthroughthe
431 optionalsoftware-basedCapacityExpansionModule.
432 6. DNSSEC validation overrides:DNSCachecanconfiguredtovalidateDNSSECsigned
433 answers.BecauseDNSSECconfigurationerrorsarenotuncommon,operatorscanreadily

DNS-Based Email Security Practice Guide


DRAFT 104
Chapter E.

434 identifydomainsfailingvalidationandspecifywhichoftheseshouldbeallowedtoresolve
435 normally.
436 7. Merge Zones:DNSCache'smergezonesfeatureallowsanumberofdynamicauthoritative
437 zonestobesplitupamongdifferentauthoritativeservers,eachofwhichisqueriedfora
438 responsetoaqueryforthatzoneuntilananswerisreceived.
439 8. Web Error Redirection Module:TheoptionalWebErrorRedirectionModuleallowsservice
440 providerstoredirectNXDOMAINresponsesfromauthoritativeserverstoaprovider-
441 brandedsearchportalthathelpsguideuserstotheirintendeddesignation.
442 9. Rules engine: DNSCache'srulesengineprovidesfine-grainedcontroloverwhichresponses
443 areredirected,andincludesbuilt-insupportforopt-out.

444 E.5.4 DNS Manager


445 DNSManagerprovidescentralizedmanagementofSecure64DNSCachesoftwareand
446 configurationsandprovidesnetwork-widemonitoringofkeyperformanceindicators.ThisGUI
447 basedapplicationcanconfigure,manage,andmonitorasetofSecure64DNSCacheservers
448 fromonecentralpoint.InanenvironmentconsistingofmanyDNSservers,therearelikelytobe
449 differencesinconfigurations.Someserversmaybeanycasted,whileothersareloadbalanced,
450 forexample.OrserverslocatedindifferentgeographiesmayhavedifferentvaluesforlocalDNS
451 data.DNSManagerallowscreationofgroupsofserversandassignsconfigurationstoagroup,a
452 singleserver,orallservers.Groupsmaybearrangedhierarchically.Commonconfiguration
453 parametersmaybeassignedtoallserversinthenetwork,whereassettingsspecifictosubsets
454 ofserversmaybeassignedatthegrouplevel,andIPaddressesandotherserver-specific
455 informationareassignedtoeachspecificserver.Allactionstomodifyconfigurationfilesor
456 softwareversionsarerevisioncontrolledandlogged.Authorizeduserscanrollbacktoprevious
457 softwareversionsorconfigurationsifnecessary.DNSManagerisabletomonitorkey
458 performanceindicatorsacrosstheDNSnetwork,includingqueriespersecond,CPU,diskand
459 memoryutilization.

460 E.5.5 Secure64 Apple Key Chain Utility


461 TheAppleKeyChainUtilityisaSecure64utilityforPublicKeyRetrievalintotheAppleKey
462 Chain.ThisutilityisdeliveredonaMacBookloadedwithAppleMailandisaprogramforthe
463 MacBookthatwillfetchSMIMEArecordsandputtheminthekeystoresothatwecan
464 demonstrateend-to-endsecurity.

DNS-Based Email Security Practice Guide


DRAFT 105
1 Appendix F Installation and Configuration Log
for NSD4, Unbound, and
OpenDNSSEC
4 ThefollowinglogcapturestheinstallationandconfigurationprocessforNSD4,Unbound,and
5 OpenDNSSECfortheNCCoE'sDNS-BasedEmailSecurityproject.PleasenotethattheIP
6 addresses,domainnames,andmailaddressesarefortheNCCoElaboratoryandmustnotbe
7 usedinactualimplementations.
8 ####
9 # Unbound installation log for 10.33.XX.XX
10 ###
11
12
13 # Unbound does not depend on a resolver for its installation. However, I
14 # configure one here so I can use yum from installation of the dependencies.
15 [rdolmans@unbound ~]$ sudo cp /etc/resolv.conf /etc/resolv.conf.orig
16 [rdolmans@unbound ~]$ echo "nameserver 10.97.XX.X" | sudo tee -a /etc/resolv.conf
17
18
19 # Install build tools
20 [rdolmans@unbound ~]$ sudo yum group install "Development Tools"
21
22
23 # Install unbound dependencies: openssl, expat
24 [rdolmans@unbound ~]$ sudo yum install openssl-devel expat-devel
25
26
27 # Download Unbound and verify
28 [rdolmans@unbound ~]$ curl https://unbound.net/downloads/unbound-1.5.8.tar.gz -o unbound-
29 1.5.8.tar.gz
30 [rdolmans@unbound ~]$ cat unbound-1.5.8.tar.gz | openssl sha256
31 (stdin)= 33567a20f73e288f8daa4ec021fbb30fe1824b346b34f12677ad77899ecd09be
32
33
34 # We do not need a nameserver anymore, move back old resolv.conf
35 [rdolmans@unbound ~]$ sudo mv /etc/resolv.conf.orig /etc/resolv.conf
36
37
38 # extract, ./configure, compile and install Unbound
39 [rdolmans@unbound ~]$ tar xvzf unbound-1.5.8.tar.gz
40 [rdolmans@unbound ~]$ cd unbound-1.5.8
41 [rdolmans@unbound unbound-1.5.8]$ ./configure
42 [rdolmans@unbound unbound-1.5.8]$ make
43 [rdolmans@unbound unbound-1.5.8]$ sudo make install
44
45
46 # Add system user and group

DNS-Based Email Security Practice Guide


DRAFT 106
Chapter F.

47 [rdolmans@unbound unbound-1.5.8]$ sudo groupadd -r unbound


48 [rdolmans@unbound unbound-1.5.8]$ sudo useradd -r -g unbound -s /sbin/nologin -c "unbound name
49 daemon" unbound
50
51
52 # Setup unbound-control, get trust anchor
53 [rdolmans@unbound ~]$ sudo unbound-control-setup
54 [rdolmans@unbound ~]$ sudo unbound-anchor
55
56
57 # Config changes:
58 # 1. Specify the interfaces to listen on
59 # 2. Allow second host to use this resolver (ACL)
60 # 3. Load DNSSEC trust anchor obtained using unbound-anchor
61 # 4. Enable remote-control (for unbound-control command, limited to localhost)
62
63
64 [rdolmans@unbound ~]$ diff -u /usr/local/etc/unbound/unbound.conf.orig /usr/local/etc/unbound/
65 unbound.conf
66 --- /usr/local/etc/unbound/unbound.conf.orig 2016-05-10 09:22:13.917495389 -0400
67 +++ /usr/local/etc/unbound/unbound.conf 2016-05-12 06:34:02.660574284 -0400
68 @@ -34,6 +34,9 @@
69 # specify 0.0.0.0 and ::0 to bind to all available interfaces.
70 # specify every interface[@port] on a new 'interface:' labelled line.
71 # The listen interfaces are not changed on reload, only on restart.
72 + interface: 192.168.3.98
73 + interface: ::1
74 + interface: 127.0.0.1
75 # interface: 192.0.2.153
76 # interface: 192.0.2.154
77 # interface: 192.0.2.154@5003
78 @@ -197,6 +200,7 @@
79 # access-control: ::0/0 refuse
80 # access-control: ::1 allow
81 # access-control: ::ffff:127.0.0.1 allow
82 + access-control: 192.168.3.0/23 allow
83
84
85 # if given, a chroot(2) is done to the given directory.
86 # i.e. you can chroot to the working directory, for example,
87 @@ -376,7 +380,7 @@
88 # you start unbound (i.e. in the system boot scripts). And enable:
89 # Please note usage of unbound-anchor root anchor is at your own risk
90 # and under the terms of our LICENSE (see that file in the source).
91 - # auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
92 + auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
93
94
95
96 # File with DLV trusted keys. Same format as trust-anchor-file.

DNS-Based Email Security Practice Guide


DRAFT 107
Chapter F.

97 # There can be only one DLV configured, it is trusted from root down.
98 @@ -614,7 +618,7 @@
99 remote-control:
100 # Enable remote control with unbound-control(8) here.
101 # set up the keys and certificates with unbound-control-setup.
102 - # control-enable: no
103 + control-enable: yes
104
105 # Set to no and use an absolute path as control-interface to use
106 # a unix local named pipe for unbound-control.
107
108
109 # Start daemon
110 [rdolmans@unbound ~]$ sudo unbound-control start
111
112
113 # add local resolver to resolv.conf
114 [rdolmans@unbound ~]$ echo "nameserver ::1" | sudo tee -a /etc/resolv.conf
115
116 # Install ldns tools (incl. drill)
117 [rdolmans@unbound ~]$ sudo yum install ldns
118
119
120 # Test DNSSEC validation
121 # 1. resolve bogus record with CD bit set, should result in answer
122 # 2. resolve bogus record with CD bit unset, should result in SERVFAIL
123
124 # CD set:
125 [rdolmans@unbound ~]$ drill txt bogus.nlnetlabs.nl @::1 -o CD
126 ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 36453
127 ;; flags: qr rd cd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 2
128 ;; QUESTION SECTION:
129 ;; bogus.nlnetlabs.nl. IN TXT
130
131
132 ;; ANSWER SECTION:
133 bogus.nlnetlabs.nl. 59 IN TXT "will be Bogus"
134
135
136 ;; AUTHORITY SECTION:
137 nlnetlabs.nl. 10200 IN NS sec2.authdns.ripe.net.
138 nlnetlabs.nl. 10200 IN NS anyns.pch.net.
139 nlnetlabs.nl. 10200 IN NS ns.nlnetlabs.nl.
140 nlnetlabs.nl. 10200 IN NS ns-ext1.sidn.nl.
141
142 ;; ADDITIONAL SECTION:
143 ns.nlnetlabs.nl. 9831 IN A 185.49.140.60
144 ns.nlnetlabs.nl. 9831 IN AAAA 2a04:b900::8:0:0:60
145
146

DNS-Based Email Security Practice Guide


DRAFT 108
Chapter F.

147 ;; Query time: 581 msec


148 ;; SERVER: ::1
149 ;; WHEN: Thu May 12 05:58:20 2016
150 ;; MSG SIZE rcvd: 209
151
152
153 # CD unset:
154 [rdolmans@unbound ~]$ drill txt bogus.nlnetlabs.nl @::1
155 ;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 14388
156 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
157 ;; QUESTION SECTION:
158 ;; bogus.nlnetlabs.nl. IN TXT
159
160 ;; ANSWER SECTION:
161
162 ;; AUTHORITY SECTION:
163
164 ;; ADDITIONAL SECTION:
165
166 ;; Query time: 0 msec
167 ;; SERVER: ::1
168 ;; WHEN: Thu May 12 05:59:06 2016
169 ;; MSG SIZE rcvd: 36
170
171
172
173 ####
174 # NSD installation log for 10.33.XX.XX
175 ###
176
177 # Add 192.168.3.98 to resolv.conf
178 [rdolmans@nsd ~]$ echo "nameserver 192.168.3.98" | sudo tee -a /etc/resolv.conf
179
180 # install openssl, libevent
181 [rdolmans@nsd ~]$ sudo yum install openssl-devel libevent-devel
182
183 # SoftHSM
184 [rdolmans@nsd ~]$ tar xvzf softhsm-2.1.0.tar.gz
185 [rdolmans@nsd ~]$ cat softhsm-2.1.0.tar.gz | openssl sha256
186 (stdin)= 0399b06f196fbfaebe73b4aeff2e2d65d0dc1901161513d0d6a94f031dcd827e
187 [rdolmans@nsd softhsm-2.1.0]$ cd softhsm-2.1.0
188 [rdolmans@nsd softhsm-2.1.0]$ autoreconf -i -f
189 # openssl version has no gost support, disable
190 [rdolmans@nsd softhsm-2.1.0]$ ./configure --disable-gost
191 [rdolmans@nsd softhsm-2.1.0]$ make
192 [rdolmans@nsd softhsm-2.1.0]$ sudo make install
193 [rdolmans@nsd softhsm-2.1.0]$ sudo softhsm2-util --init-token --slot 0 --label "OpenDNSSEC"
194
195 # LDNS (incl. examples and drill)

DNS-Based Email Security Practice Guide


DRAFT 109
Chapter F.

196 [rdolmans@nsd ~]$ curl https://nlnetlabs.nl/downloads/ldns/ldns-1.6.17.tar.gz -o ldns-


197 1.6.17.tar.gz
198 [rdolmans@nsd ~]$ cat ldns-1.6.17.tar.gz | openssl sha1
199 (stdin)= 4218897b3c002aadfc7280b3f40cda829e05c9a4
200 [rdolmans@nsd ~]$ tar xvzf ldns-1.6.17.tar.gz
201 [rdolmans@nsd ~]$ cd ldns-1.6.17
202 [rdolmans@nsd ldns-1.6.17]$ ./configure --with-examples --with-drill
203 [rdolmans@nsd ldns-1.6.17]$ make
204 [rdolmans@nsd ldns-1.6.17]$ sudo make install
205
206 # OpenDNSSEC
207 # install dependencies: SQLite3, libxml2, java (for now)
208 [rdolmans@nsd ~]$ sudo yum install libxml2-devel sqlite-devel java-1.8.0-openjdk-devel
209 [rdolmans@nsd ~]$ git clone https://github.com/opendnssec/opendnssec.git
210 [rdolmans@nsd ~]$ cd opendnssec
211 [rdolmans@nsd opendnssec]$ sh autogen.sh
212 [rdolmans@nsd opendnssec]$ ./configure
213 [rdolmans@nsd opendnssec]$ make
214 [rdolmans@nsd opendnssec]$ sudo make install
215
216
217 # Setup SQLite db
218 [rdolmans@nsd opendnssec]$ sudo ods-enforcer-db-setup
219
220 # Use SoftHSM2, reload NSD zone after signing
221 [rdolmans@nsd ~]$ sudo diff -u /etc/opendnssec/conf.xml.sample /etc/opendnssec/conf.xml
222 --- /etc/opendnssec/conf.xml.sample 2016-05-12 10:53:35.154584441 -0400
223 +++ /etc/opendnssec/conf.xml 2016-05-17 12:03:20.719795941 -0400
224 @@ -5,9 +5,9 @@
225 <RepositoryList>
226
227 <Repository name="SoftHSM">
228 - <Module>/usr/local/lib/softhsm/libsofthsm.so</Module>
229 + <Module>/usr/local/lib/softhsm/libsofthsm2.so</Module>
230 <TokenLabel>OpenDNSSEC</TokenLabel>
231 - <PIN>1234</PIN>
232 + <PIN>**********</PIN>
233 <SkipPublicKey/>
234 </Repository>
235
236 @@ -87,9 +87,7 @@
237 <!--
238 < NotifyCommand>/usr/local/bin/my_nameserver_reload_command</
239 NotifyCommand>
240 -->
241 -<!--
242 - <NotifyCommand>/usr/sbin/rndc reload %zone</NotifyCommand>
243 --->
244 + <NotifyCommand>/usr/local/sbin/nsd-control reload %zone</NotifyCommand>
245 </Signer>

DNS-Based Email Security Practice Guide


DRAFT 110
Chapter F.

246
247
248 </Configuration>
249
250
251 # Add policy to KASP config file. We use a policy named dnslab here, which is based on policy
252 default (but uses NSEC).
253 # See /etc/opendnssec/kasp.xml
254
255 [rdolmans@nsd ~]$ sudo ods-enforcer update all
256 Created policy dnslab successfully
257 Policy dnslab already up-to-date
258 update all completed in 0 seconds.
259 [rdolmans@nsd ~]$ sudo ods-enforcer policy list
260 Policy: Description:
261 dnslab Policy used for the NCCOE dnslab
262 policy list completed in 0 seconds.
263 [rdolmans@nsd ~]$ sudo ods-enforcer zone add --zone nev1.dnslab.nccoe.nist.gov --policy dnslab
264 Zone nev1.dnslab.nccoe.nist.gov added successfully
265 zone add completed in 1 seconds.
266
267
268
269 # NSD
270 # Download, verify checksum, extract, configure, compile and install NSD
271 [rdolmans@nsd ~]$ curl https://nlnetlabs.nl/downloads/nsd/nsd-4.1.9.tar.gz -o nsd-4.1.9.tar.gz
272 [rdolmans@nsd ~]$ cat nsd-4.1.9.tar.gz | openssl sha256
273 (stdin)= b811224d635331de741f1723aefc41adda0a0a3a499ec310aa01dd3b4b95c8f2
274 [rdolmans@nsd ~]$ tar xvzf nsd-4.1.9.tar.gz
275 [rdolmans@nsd ~]$ cd nsd-4.1.9
276 [rdolmans@nsd nsd-4.1.9]# ./configure --with-pidfile=/var/run/nsd/nsd.pid
277 [rdolmans@nsd nsd-4.1.9]$ make
278 [rdolmans@nsd nsd-4.1.9]$ sudo make install
279 [rdolmans@nsd ~]$ sudo nsd-control-setup
280
281 # enable in config
282 [rdolmans@nsd ~]$ sudo cp /etc/nsd/nsd.conf.sample /etc/nsd/nsd.conf
283 [rdolmans@nsd ~]$ diff -u /etc/nsd/nsd.conf.sample /etc/nsd/nsd.conf
284 --- /etc/nsd/nsd.conf.sample 2016-05-17 11:46:58.379795464 -0400
285 +++ /etc/nsd/nsd.conf 2016-05-18 07:06:14.861829191 -0400
286 @@ -23,6 +23,9 @@
287 # ip-address: 1.2.3.4
288 # ip-address: 1.2.3.4@5678
289 # ip-address: 12fe::8ef0
290 + ip-address: 192.168.3.99
291 + ip-address: ::1
292 + ip-address: 127.0.0.
293 # Allow binding to non local addresses. Default no.
294 # ip-transparent: no
295 @@ -62,7 +65,7 @@

DNS-Based Email Security Practice Guide


DRAFT 111
Chapter F.

296
297 # the database to use
298 # if set to "" then no disk-database is used, less memory usage.
299 - # database: "/var/db/nsd/nsd.db"
300 + database: ""
301
302 # log messages to file. Default to stderr and syslog (with
303 # facility LOG_DAEMON). stderr disappears when daemon goes to bg.
304 @@ -141,7 +144,7 @@
305 remote-control:
306 # Enable remote control with nsd-control(8) here.
307 # set up the keys and certificates with nsd-control-setup.
308 - # control-enable: no
309 + control-enable: yes
310
311 # what interfaces are listened to for control, default is on localhost.
312 # control-interface: 127.0.0.1
313 @@ -249,4 +252,10 @@
314 # zonefile: "example.com.zone"
315 # request-xfr: 192.0.2.1 example.com.key
316
317 -
318 +pattern:
319 + name: "local-signed"
320 + zonefile: "/var/opendnssec/signed/%s"
321 +
322 +zone:
323 + name: "nev1.dnslab.nccoe.nist.gov"
324 + include-pattern: "local-signed"
325
326
327 [rdolmans@nsd ~]$ sudo groupadd -r nsd
328 [rdolmans@nsd ~]$ sudo useradd -r -g nsd -s /sbin/nologin -c "nsd daemon" nsd
329
330 # Make user nsd the owner of the nsd db and run directories
331 [rdolmans@nsd ~]# sudo chown nsd:nsd /var/db/nsd/
332 [rdolmans@nsd ~]# sudo chown nsd:nsd /var/run/nsd
333
334 # Start NSD
335 [rdolmans@nsd ~]$ sudo nsd-control start
336
337 # Export DS
338 [rdolmans@nsd ~]$ sudo ods-enforcer key export --zone nev1.dnslab.nccoe.nist.gov --ds
339 ;ready KSK DS record (SHA1):
340 nev1.dnslab.nccoe.nist.gov. 3600 IN DS 35674 8 1
341 79ee1e53ce23658b6d5632297336b3067a80e329
342 ;ready KSK DS record (SHA256):
343 nev1.dnslab.nccoe.nist.gov. 3600 IN DS 35674 8 2
344 0bd77d723e0a6d602a82bf0173a32a8286cfa4d602100e716192425544fb43a2
345 key export completed in 0 seconds.

DNS-Based Email Security Practice Guide


DRAFT 112
Chapter F.

346
347
348 Generate key + selfsigned cert:
349
350 [rdolmans@unbound cert]$ sudo openssl req -newkey rsa:2048 -nodes \
351 -keyout nev1.dnslab.nccoe.nist.gov.key -x509 -days 365 -out nev1.dnslab.nccoe.nist.gov.crt
352 Generating a 2048 bit RSA private key
353 ....................+++
354 .......................................+++
355 writing new private key to 'nev1.dnslab.nccoe.nist.gov.key'
356 -----
357 You are about to be asked to enter information that will be incorporated into your certificate
358 request.
359 What you are about to enter is what is called a Distinguished Name or a DN.
360 There are quite a few fields but you can leave some blank
361 For some fields there will be a default value,
362 If you enter '.', the field will be left blank.
363 -----
364 Country Name (2 letter code) [XX]:NL
365 State or Province Name (full name) []:
366 Locality Name (eg, city) [Default City]:Amsterdam
367 Organization Name (eg, company) [Default Company Ltd]:NLnet Labs
368 Organizational Unit Name (eg, section) []:
369 Common Name (eg, your name or your server's hostname) []:nev1.dnslab.nccoe.nist.gov
370 Email Address []:
371
372
373 # Generate TLSA record for cert:
374
375 [rdolmans@unbound cert]$ ldns-dane create nev1.dnslab.nccoe.nist.gov 25 3 1 1 -c
376 nev1.dnslab.nccoe.nist.gov.crt
377 _25._tcp.nev1.dnslab.nccoe.nist.gov. 3600 IN TLSA 3:
378 1 1 0e8f0af01ea3c87bb5647de3f36cd7ab1eedf5ae466edf5a8800f6174884f60d
379
380 # Add TLSA and MX records to zone:
381
382 [rdolmans@nsd unsigned]$ diff -u nev1.dnslab.nccoe.nist.gov.old nev1.dnslab.nccoe.nist.gov
383 --- nev1.dnslab.nccoe.nist.gov.old 2016-05-31 10:13:17.728379254 -0400
384 +++ nev1.dnslab.nccoe.nist.gov 2016-05-31 10:13:21.403379256 -0400
385 @@ -9,7 +9,10 @@
386
387
388 NS ns.nev1.dnslab.nccoe.nist.gov.
389 A 192.168.3.99
390 + MX 10 192.168.3.98
391
392
393 TXT "dnslab test zone."
394
395

DNS-Based Email Security Practice Guide


DRAFT 113
Chapter F.

396 ns IN A 192.168.3.99
397 +
398 +_25._tcp IN TLSA 3 1 1 0e8f0af01ea3c87bb5647de3f36cd7ab1eedf5ae466edf5a8800f6174884f60d
399
400 # Resign
401 [rdolmans@nsd unsigned]$ sudo ods-signer sign nev1.dnslab.nccoe.nist.gov
402 Zone nev1.dnslab.nccoe.nist.gov scheduled for immediate re-sign.

403

DNS-Based Email Security Practice Guide


DRAFT 114
1 Appendix G Microsoft Installation for the
NCCoE
3 ThefollowinglogcapturestheinstallationandconfigurationprocessforMicrosoftsystemand
4 applicationssoftwarefortheNCCoE'sDNS-BasedEmailSecurityproject.PleasenotethattheIP
5 addresses,domainnames,andmailaddressesarefortheNCCoElaboratoryandmustnotbe
6 usedinactualimplementations.

7 G.1 Microsoft Server


8 TwoMicrosoftActiveDirectorydomainswerebuiltforthisproject.MS1.DNSLAB.DNSOPS.GOV
9 andMS2.DNSLAB.DNSOPS.GOVdomains.TwoversionsofWindowsServerwereused.
10 WindowsServer2016TechnicalPreview5,StandardGUIedition(WS2016TP5)whichis
11 availablefromtheMicrosoftEvaluationCenter(https://www.microsoft.com/en-us/evalcenter/
12 evaluate-windows-server-technical-preview);andActiveDirectoryDomainServiceswith
13 integratedDomainNameServicesandCertificateServicesrunonWS2016TP5.Currently,
14 Exchange2016runsonWindowsServer2012R2duetoExchangerequirements(https://
15 technet.microsoft.com/en-us/library/aa996719(v=exchg.160).aspx).
16 TheprocessionofMicrosoftServicestobeinstalledandconfiguredisasfollows:
17 1. ActiveDirectoryDomainServices
18 2. ActiveDirectoryCertificateServices-RootCertificationAuthority
19 3. ActiveDirectoryCertificateServices-IssuingCertificationAuthority
20 4. ActiveDirectoryDomainNameServices
21 5. Exchange2016

DNS-Based Email Security Practice Guide


DRAFT 115
Chapter G.

22

23 G.2 Active Directory Domain Services


24 ThefollowingprocedureswereusedforthecreationoftheMS1.DNSLAB.DNSOPS.GOVActive
25 DirectorydomainontheEV1-DC1.MS1.DNSLAB.DNSOPS.GOVWS2016TP5server.
26 1. StaticallyassignIPaddressoftheDomainController.Thisdomaincontrollerservesasthe
27 DNSserverfortheMS1.DNSLAB.DNSOPS.GOVActivedirectorydomain:
28 a. IPAddress:192.168.1.12
29 b. Netmask:255.255.255.0
30 c. Gateway:192.168.1.1
31 d. DNSServer192.168.1.12
32 2. InstallActiveDirectoryDomainServices(ADDS)role:
33 a. Server Manager -> Manage -> Add Roles and Features
34 b. Installation type -> Role-based or feature based installation
35 c. Server Selection -> local server
36 d. Server Roles ->SelectActive Directory Domain Services,accepttheFeaturestobe
37 addedwiththeinstallationofADDS.
38 e. OntheFeaturesselectionmenuclickNext.

DNS-Based Email Security Practice Guide


DRAFT 116
Chapter G.

39 f. ClickInstall.
40 g. OnceinstallationiscompleteclickClose.
41 3. ConfiguretheActiveDirectoryDomainServices.
42 a. InServerManagerclicktheexclamation markunderneaththeflagiconandclickon
43 Promote this server to a domain controller.

44

45 b. Deployment Configuration -> Add a new forestandspecifytherootnameof


46 MS1.DNSLAB.DNSOPS.GOV.

47

48 c. InDomain Controller OptionsselectthedefaultsandsettheDirectory Services Restore


49 Mode (DSRM) password.
50 d. DNSOptions-parentzonecouldnotbefound,clickNext.
51 e. TheNetBiosdomainnamewilldefaulttothelowestleveloftheFQDNoftheForest,i.e.
52 MS1.
53 f. AcceptthedefaultpathsfortheADDSDatabase,LogandSysVolfolders.Ifrunningona
54 virtualmachine,followtherecommendedpracticeofthevirtualizationhost.

DNS-Based Email Security Practice Guide


DRAFT 117
Chapter G.

55 g. InthePrerequisitesCheckyouwillbenotifiedthattheDNScannotbedelegated.The
56 DNSserverwillbehostedonthisdomaincontroller.

57 G.3 Active Directory Certificate Services: Microsoft


58 Certificate Authority
59 WindowsServer2016TP5ActiveDirectoryCertificateServices(ADCS)servesasthePublicKey
60 InfrastructurefortheMS1.DNSLAB.DNSOPS.GOVnamespace.Itisatwo-tierhierarchywith
61 EV1-ROOT.MS1.DNSLAB.DNSOPS.GOVastherootCertificationAuthority(CA)trustpoint,and
62 EV1-ISSUING.MS1.DNSLAB.DNSOPS.GOVasthedomainjoinedenterpriseissuingCA.

63 G.3.1 Root CA Installation


64 TheinstallationofActiveDirectoryCertificateServicesmustbeperformedbyanenterprise
65 administrator.
66 1. CopyCAPolicy.inftothec:\windowsdirectory:
67 ; NCCoE DANE DNSSEC Building Block
68
69 [Version]
70 Signature= "$Windows NT$"
71
72 ; Configures CA to allow only a single tier of CAs below it
73 [BasicConstraintsExtension]
74 PathLength = 1
75
76 ; Allows all issuance policies, sets HTTP pointer for CPS
77 [PolicyStatementExtension]
78 Policies = AllIssuancePolicy, LegalPolicy
79 Critical = 0
80
81 [AllIssuancePolicy]
82 OID = 2.5.29.32.0
83
84 [LegalPolicy]
85 OID = 1.1.1.1.1
86 Notice = "http://pki.ms1.dnslab.dnsops.gov/CPS.htm"
87 URL = "http://pki.ms1.dnslab.dnsops.gov/CPS.htm"
88
89 ; Sets key renewal and CRL publication parameters
90 [Certsrv_Server]
91 RenewalKeyLength = 4096
92 RenewalValidityPeriod = Years
93 RenewalValidityPeriodUnits = 20
94 CRLPeriod = days
95 CRLPeriodUnits = 180
96 CRLDeltaPeriodUnits = 0

DNS-Based Email Security Practice Guide


DRAFT 118
Chapter G.

97 CRLDeltaPeriod = days
98
99 ; Makes the CDP and AIA pointer for the root CA cert blank
100 [CRLDistributionPoint]
101 Empty = True
102
103 [AuthorityInformationAccess]
104 Empty = True
105
106 ; NCCoE DANE DNSSEC Building Block
107
108 [Version]
109 Signature= "$Windows NT$"
110
111 ; Configures CA to allow only a single tier of CAs below it
112 [BasicConstraintsExtension]
113 PathLength = 1
114
115 ; Allows all issuance policies, sets HTTP pointer for CPS
116 [PolicyStatementExtension]
117 Policies = AllIssuancePolicy, LegalPolicy
118 Critical = 0
119
120 [AllIssuancePolicy]
121 OID = 2.5.29.32.0
122
123 [LegalPolicy]
124 OID = 1.1.1.1.1
125 Notice = "http://pki.ms1.dnslab.dnsops.gov/CPS.htm"
126 URL = "http://pki.ms1.dnslab.dnsops.gov/CPS.htm"
127
128 ; Sets key renewal and CRL publication parameters
129 [Certsrv_Server]
130 RenewalKeyLength = 4096
131 RenewalValidityPeriod = Years
132 RenewalValidityPeriodUnits = 20
133 CRLPeriod = days
134 CRLPeriodUnits = 7
135 CRLDeltaPeriodUnits = 0
136 CRLDeltaPeriod = days
137
138 ; Makes the CDP and AIA pointer for the root CA cert blank
139 [CRLDistributionPoint]
140 Empty = True
141
142 [AuthorityInformationAccess]
143 Empty = True
144

DNS-Based Email Security Practice Guide


DRAFT 119
Chapter G.

145 2. Server Manager -> Manage -> Add Roles and Features.
146 3. Installation type -> Role-basedorfeature basedinstallation.
147 4. Server Selection -> local server.
148 5. Server Roles ->SelectActive Directory Certificate Services,accepttheFeaturestobe
149 addedwiththeinstallationofADCS.
150 6. OntheFeaturesselectionmenuclickNext.
151 7. ClickInstall.
152 8. OnceinstallationiscompleteclickClose.

153 G.3.1.1 Configure Root CA


154 1. Run post install configuration wizard,clickonConfigure Active Directory Certificate
155 Serviceslink:

156

157 2. SelectRole Services to configure ->selectCertification Authority.


158 3. SetupType=Standalone CA.
159 4. CAType=Root CA.
160 5. PrivateKey=Create a new private key.
161 6. Cryptography:
162 a. Cryptographicprovider->RSA#Microsoft Software Key Storage Provider
163 b. HashingAlgorithm=SHA256
164 c. KeyLength2048
165 7. CAName=EV1-Root
166 8. Oncecompleted,run the post install script.

DNS-Based Email Security Practice Guide


DRAFT 120
Chapter G.

167 :: NCCoE DANE DNSSEC Building Block


168
169 :: Declares configuration NC
170 certutil -setreg CA\DSConfigDN CN=Configuration,DC=ms1,DC=dnslab,DC=dnsops,DC=gov
171
172 :: Defines CRL publication intervals
173 certutil -setreg CA\CRLPeriodUnits 7
174 certutil -setreg CA\CRLPeriod "Days"
175 certutil -setreg CA\CRLDeltaPeriodUnits 0
176 certutil -setreg CA\CRLDeltaPeriod "Days"
177
178 :: Specifies CDP attributes
179 certutil -setreg CA\CRLPublicationURLs
180 "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n6:http://pki.ms1.dnslab.dnsops.gov/
181 %%3%%8%%9.crl\n14:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n"
182
183 :: Specifies AIA attributes
184 certutil -setreg CA\CACertPublicationURLs
185 "1:%windir%\system32\CertSrv\CertEnroll\%%7.crt\n2:http://pki.ms1.dnslab.dnsops.gov/
186 %%7.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n"
187
188 :: Enables auditing all events for the CA
189 certutil -setreg CA\AuditFilter 127
190
191 :: Sets validity period for issued certificates
192 certutil -setreg CA\ValidityPeriodUnits 10
193 certutil -setreg CA\ValidityPeriod "Years"
194
195 :: Restarts Certificate Services
196 net stop certsvc & net start certsvc
197
198 :: Republishes the CRL; sometimes this gets an access denied (error 5) because the service is not
199 ready after restart, in this case, manually execute
200 certutil -crl

201 G.3.1.2 Enable Certificate Services Auto Enrollment within the Active Directory Domain
202 1. LogontothedomaincontrollerEV1-DC1.MS1.DNSLAB.DNSOPS.GOV.
203 2. StartGroup Policy Management console(gpmc.msc).
204 3. NavigatetotheDefault Domain Policy.
205 4. WithintheDefaultDomainPolicygotoComputer Configuration -> Policies -> Windows
206 Settings -> Security Settings -> Public Key Policies
207 5. SelecttheCertificate Services Client - Certificate Enrollment Policysetting.
208 6. SettoEnabled,ensurethedefault Active Directory Enrollment Policyisselectedandclick
209 OK.

DNS-Based Email Security Practice Guide


DRAFT 121
Chapter G.

210

211 7. SelectCertificate Services Client - Auto-Enrollmentsetting.

212

213 8. SetConfiguration ModeltoEnabled.


214 9. Enable Renew Expired CertificatesandUpdate certificates that use certificate templates
215 radiobuttons.

DNS-Based Email Security Practice Guide


DRAFT 122
Chapter G.

216 G.3.2 Issuing a CA Installation


217 1. StartadministrativecommandpromptasanEnterpriseAdministrator.
218 2. PublishtheEV1-RootCAcertificatetoActiveDirectoryfordisseminationtoallsystems
219 withintheMS1.DNSLAB.DNSOPS.GOVActiveDirectorydomain.Fromanadministrative
220 commandprompt,typecertutil -dspublish -f ev1-root.crt rootca.
221 3. Fromtheadministrativecommandprompt,typecertutil -pulsefollowedbygpupdate /
222 force.

223 4. CopyCAPolicy.inftothec:\windowsdirectory.
224
225 ; NCCoE DANE DNSSEC Building Block
226
227 [Version]
228 Signature= "$Windows NT$"
229
230 ; Allows all issuance policies, sets HTTP pointer for CPS
231 [PolicyStatementExtension]
232 Policies = AllIssuancePolicy, LegalPolicy
233 Critical = 0
234
235 [AllIssuancePolicy]
236 OID = 2.5.29.32.0
237
238 [LegalPolicy]
239 OID = 1.1.1.1.1
240 Notice = "http://pki.ms1.dnslab.dnsops.gov/cps.htm"
241 URL = "http://pki.ms1.dnslab.dnsops.gov/CPS.htm"
242
243 ; Sets key renewal and CRL publication parameters
244 [certsrv_server]
245 renewalkeylength = 2048
246 RenewalValidityPeriodUnits = 10
247 RenewalValidityPeriod = years
248 CRLPeriod = hours
249 CRLPeriodUnits = 36
250 CRLDeltaPeriod = hours
251 CRLDeltaPeriodUnits = 0
252

253 5. Server Manager -> Manage -> Add Roles and Features.
254 6. Installation type -> Role-basedorfeature based installation.
255 7. Server Selection -> local server.
256 8. Server Roles -> Select Active Directory Certificate Services,accepttheFeaturestobe
257 addedwiththeinstallationofADCS.
258 9. Features=Certification AuthorityandCertification Authority Web Enrollment(thiswill
259 addtherequiredIISfeatures).
260 10. OntheFeaturesselectionmenuclickNext.

DNS-Based Email Security Practice Guide


DRAFT 123
Chapter G.

261 11. ClickInstall.


262 12. OnceinstallationiscompleteclickClose.
263 13. RunthePost-Deployment configuration for the ADCS role.

264

265 14. SelectbothCertification AuthorityandCertification Authority Web Enrollment.

266

267 15. SetupType=Enterprise CA


268 16. CAType=Subordinate CA
269 17. Create new key(sameasabove).
270 18. CAName=EV1-Issuing
271 a. PrivateKey=Create a new private key
272 b. Cryptography:
273 i. Cryptographicprovider->RSA#Microsoft Software Key Storage Provider
274 ii. HashingAlgorithm=SHA256

DNS-Based Email Security Practice Guide


DRAFT 124
Chapter G.

275 iii. KeyLength2048


276 19. Savetherequestfiletothec:\ drive.
277 20. Copyrequestfiletoroot ca.
278 21. OnRootCA,issue certificate.
279 22. Importev1-issuing.ca intotheCertification Authority.
280 23. CreateaCNAMErecordforPKI.MS1.DNSLAB.DNSOPS.GOVtopointtoev1-
281 issuing.ms1.dnslab.dnsops.gov.

282

283 24. OpenInternet Information Service Manager.


284 25. GototheDefault Web Site.
285 26. Bindings:edittheexistingdefaultHTTPbindingandaddpki.ms1.dnslab.dnsops.gov.
286 27. ClickontheFilter requests -> SelectAllow File name Extensionandadd.crl,.crtand.cer.
287 28. Fromanadministrativecommandprompttypeiisreset.
288 29. OntheIssuingCArunthepostinstallscript.
289 :: NCCoE DANE DNSSEC Building Block
290
291 :: Declares configuration NC
292 certutil -setreg CA\DSConfigDN CN=Configuration,DC=MS1,DC=DNSLAB,DC=DNSOPS,DC=GOV
293
294 :: Defines CRL publication intervals
295 certutil -setreg CA\CRLPeriodUnits 3
296 certutil -setreg CA\CRLPeriod "days"
297 certutil -setreg CA\CRLDeltaPeriodUnits 0
298 certutil -setreg CA\CRLDeltaPeriod "Hours"
299
300 :: Specifies CDP attributes
301 certutil -setreg CA\CRLPublicationURLs
302 "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n6:http://pki.ms1.dnslab.dnsops.gov/
303 %%3%%8%%9.crl\n79:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n"
304
305 :: Specifies AIA attributes

DNS-Based Email Security Practice Guide


DRAFT 125
Chapter G.

306 certutil -setreg CA\CACertPublicationURLs


307 "1:%windir%\system32\CertSrv\CertEnroll\%%7.crt\n2:http://pki.ms1.dnslab.dnsops.gov/
308 %%7.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n"
309
310 :: Enables auditing all events for the CA
311 certutil -setreg CA\AuditFilter 127
312
313 :: Sets maximum validity period for issued certificates
314 certutil -setreg CA\ValidityPeriodUnits 5
315 certutil -setreg CA\ValidityPeriod "Years"
316
317 :: Restarts Certificate Services
318 net stop certsvc & net start certsvc
319
320 :: Republishes the CRL; sometimes this gets an access denied (error 5) because the service is not
321 ready after restart, in this case, manually execute
322 certutil -CRL

323 G.4 Microsoft Domain Name Services: DNS Domain


324 Server
325 ActiveDirectoryDomainServicesinstallationinstallsandconfiguresthems1.dnslab.dnsops.gov
326 Forwardlookupzone.ItisrecommendedtocreateaReverselookupzoneforthesubnetsused.

327

328 1. Createaconditionalforwarderfortheothernamespaces:

DNS-Based Email Security Practice Guide


DRAFT 126
Chapter G.

329

330 2. Createforwardedtodnslab.dnsops.gov.

331

332 G.5 Microsoft Exchange


333 Exchange2016wasinstalledonaWindowsServer2012R2Standard(ServerwithaGUI).
334 Exchange2016iscurrentlynotsupportedonWindowsServer2016TechnicalPreview2016
335 https://technet.microsoft.com/en-us/library/aa996719(v=exchg.160).aspx.
336 Exchange2016prerequisitescanbefoundhere:https://technet.microsoft.com/en-us/library/
337 bb691354(v=exchg.160).aspx.

DNS-Based Email Security Practice Guide


DRAFT 127
Chapter G.

338 Downloadfor.Net4.5.2:https://www.microsoft.com/en-us/download/details.aspx?id=42642.
339 1. InstalltheRemoteToolsAdministrationPackusingthefollowingpowershellcommand:
340 Install-WindowsFeature RSAT-ADDS.

341 2. InstallExchange2016prerequisiteswiththefollowingpowershellcommand:
342 Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-
343 Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-
344 Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell,
345 Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-
346 Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-
347 Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-
348 ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-
349 Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server,
350 Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI,
351 Windows-Identity-Foundation
352 3. PerformActiveDirectorySchemaupdatefollowingtheTechnetarticle,PrepareActive
353 DirectoryandDomains:https://technet.microsoft.com/en-us/library/
354 bb125224(v=exchg.160).aspx.
355 4. InstalltheMailbox role.

356

357 5. OncetheinstallationiscompletedgototheExchange Admin console:https://ev1-


358 exch.ms1.dnslab.dnsops.gov/ECP.
359 6. CreateanInternet send connectorfollowingthisTechnetarticle:https://
360 technet.microsoft.com/en-us/library/jj657457(v=exchg.160).aspx.
361 7. CreateanSSL certificatefortheExchangeservices.

DNS-Based Email Security Practice Guide


DRAFT 128
Chapter G.

362 8. OntheIssuingCA(ev1-issuing),openCertification Authority -> Certificate Templates.


363 9. Right click -> Manage.
364 10. RightclickontheWeb Server templateandselectduplicate.
365 11. Compatibility=Windows Server Technical Preview

366

367 12. General -> Template Display Name MS1 Web Server

DNS-Based Email Security Practice Guide


DRAFT 129
Chapter G.

368

369 13. Security -> Domain Computers allowed to Enroll for certificate

DNS-Based Email Security Practice Guide


DRAFT 130
Chapter G.

370

371 14. Subject Name -> Supply in Request

372

DNS-Based Email Security Practice Guide


DRAFT 131
Chapter G.

373 15. ClickOKtosavethenewMS1WebServercertificatetemplate.


374 16. BackintheCertificationAuthoritysnap-in,rightclickonCertificate Templates -> Certificate
375 to Issue,thenselecttheMS1 Web Servercertificatetemplate.

376

377 17. OntheExchangeserver(ev1-exch),logonasanadministratorandtypecertlm.msc.


378 18. GotoPersonal -> Certificates -> right click -> request new certificate.

379

380 19. SubjectName:Common Name = ev1-exch.ms1.dnslab.dnsops.gov


381 20. AlternativeName:DNS = ev1-exch.ms1.dnslab.dnsops.gov, ms1.dnslab.dnsops.gov,
382 1.ms1.dnslab.dnsops.gov, 2.ms1.dnslab.dnsops.gov
383 21. ClickOKandthenselectenroll.
384 22. UsethiscertificatetoprotecttheExchangeservices.
385 23. WithintheExchangeAdminconsole(https://ev1-exch.ms1.dnslab.dnsops.gov/ECP),select
386 Server -> Certificates,thenchangeallservicestousetheissuedSSLcertificate.

DNS-Based Email Security Practice Guide


DRAFT 132
Chapter G.

387

388

389 24. SelectalltheservicesexceptforUnified Messaging.

DNS-Based Email Security Practice Guide


DRAFT 133
Chapter G.

390

391 G.5.1 Generate the TLS DNS Record


392 1. Signthems1.dnslab.dnsops.govzonebyfollowingtheTechnetarticleforenablingDNSSEC
393 https://technet.microsoft.com/en-us/library/hh831411.aspx.
394 2. ExporttheExchange SSL certificatetoa.cerfile.FindthecertificateontheIssuingCA(ev1-
395 issuing)withintheIssued Certificatesgroup.

DNS-Based Email Security Practice Guide


DRAFT 134
Chapter G.

396

397 3. ClickontheDetailstabandselectCopy to File.Saveasabase64 (.cer)file.

DNS-Based Email Security Practice Guide


DRAFT 135
Chapter G.

398

399 4. Gotohttps://www.huque.com/bin/gen_tlsa.Opentheexportedcertificateintonotepad,
400 thecopy and pasteintotheEnter/paste PEM format X.509 certificate herefield.
401 5. Fillinthenamespacespecificinformation.

402

403 6. SelectGenerateandtheTLSArecordstringispresentedback.
404 _443._tcp.ms1.dnslab.dnsops.gov. IN TLSA 3 1 1
405 25d645a7bd304ae552c629ca5e7061a70f921afc4dd49c1ea0c8f22de6595be7

DNS-Based Email Security Practice Guide


DRAFT 136
Chapter G.

406

407 7. ToregisterthisTLSArecordwithinWindowsServer2016ActiveDirectoryDomainName
408 Services,issuethefollowingpowershellcommandontheDomainControlleras
409 Administrator:
410 add-dnsserverresourcerecord -TLSA -CertificateAssociationData
411 "25d645a7bd304ae552c629ca5e7061a70f921afc4dd49c1ea0c8f22de6595be7" -
412 CertificateUsage DomainIssuedCertificate -MatchingType Sha256Hash -Selector
413 FullCertificate -ZoneName ms1.dnslab.dnsops.gov -Name _25._tcp.ev1-
414 exch.ms1.dnslab.dnsops.gov.
415 8. Togetthezoneoutput,issuethefollowingpowershellcommand:
416 Resolve-DnsName ev1-dc1.ms1.dnslab.dnsops.gov -type soa -server ev1-dc1 -
417 DnssecOk

418 G.5.2 Issue S/MIME Certificates and Configure Outlook


419 ToissueanS/MIMEDigitalSignaturecertificatetotheuser,gototheIssuingCA(ev1-issuingca).
420 1. OpentheCertification Authoritysnap-in,rightclickonCertificate Templatesandselect
421 Manage.
422 2. FindtheExchange Signature Onlycertificatetemplate,rightclickandselectduplicate.
423 3. SetCompatibilitytoWindows Server 2012 R2.

DNS-Based Email Security Practice Guide


DRAFT 137
Chapter G.

424

425 4. WithintheGeneraltabprovideanameforthenewtemplate.

426

DNS-Based Email Security Practice Guide


DRAFT 138
Chapter G.

427 5. IntheCryptographytabselectRequest can use any provider available on the subject's


428 computer.

429

430 6. IntheSecuritytab,selectAuthenticated UsersfromGroup or user names,andallowRead


431 andEnroll.

DNS-Based Email Security Practice Guide


DRAFT 139
Chapter G.

432

433 7. IntheSubject Nametab,selectBuild for this Active Directory information -> Email name
434 (note:makesurethemailattributeontherecipient'sActiveDirectoryobjectispopulated
435 withthecorrectemailaddress)

DNS-Based Email Security Practice Guide


DRAFT 140
Chapter G.

436

437 8. OntheWindows10workstation,logonastheuserthatwillreceivetheS/MIMEDigital
438 Signaturecertificate.Startcertmgr.msc -> Personal -> right click: all tasks -> request new
439 certificate.
440 9. SelecttheActive Directory Enrollment Policy ->selectthecertificatetemplatethatwasjust
441 createdandfollowtheprompts.
442 10. Oncecompleted,theS/MIMEdigitalsignaturecertificatewillbeintheuser'sPersonal->
443 CertificatestoreandcanbeusedforS/MIMEdigitalsignaturewithinOutlook.
444 11. ToconfigureOutlooktousethenewS/MIMEcertificate:
445 a. OpenOutlook 2016.
446 b. ClickonFile,andthenOptions.
447 c. Intheleft-handmenuclickonTrust Center.
448 d. ClickontheTrust Center Settingsbox.

DNS-Based Email Security Practice Guide


DRAFT 141
Chapter G.

449

450 e. ClickEmail Securityintheleft-handmenu.

451

DNS-Based Email Security Practice Guide


DRAFT 142
Chapter G.

452 f. ClicktheSettingsbuttonwithintheEncrypted Emailsection.


453 g. EnteranamewithintheSecurity Settings Namefield.
454 h. SelecttheSigning CertificatebyclickingontheChoosebuttonforthesigning
455 certificate,andselecttheHash Algorithm.
456 i. IfyouhaveanS/MIMEencryptioncertificateselecttheChoosebuttonforthe
457 encryptioncertificateandselecttheEncryption Algorithm.
458 j. SelecttheradiobuttonSend these certificates with signed messages.

459

DNS-Based Email Security Practice Guide


DRAFT 143
1 Appendix H Installation and Configuration of
DNS Authority, DNS Cache, and DNS
Signer at the NCCoE
4 TheNCCoElabcontainedoneDNSSignerappliance,andoneVMinstanceeachofDNS
5 AuthorityandDNSCache.Thesesystemswerenotsubjecttospecialconfigurationsbeyond
6 normalnetworkconfiguration.ThenormalinstallationandsetupforSecure64productsis
7 foundinthedocumentation(onlineat:https://support.secure64.com/).
8 TherearenospecialconfigurationoptionsneededforsupportingDANEawaremailserversor
9 clientswithSecure64DNSproducts.DANEResourceRecordtypesaretreatedasanyothervalid
10 DNSRRtype.

11 H.1 DNS Signer


12 OncetheDNSSignerapplianceisinstalledandinitiallysetup,therearenospecialconfiguration
13 optionsneededwhendeployingDANEtosupportemail.Onceacertificateisobtained(or
14 generated)fortheSMTPserver,aTLSARRneedstobegeneratedandaddedtothezone.This
15 canbedoneusingoneofthetoolsorwebsitesdescribedinSection3.4above.OncetheTLSA
16 RRisgenerated,thezonecanbemanuallyupdatedbyeditingthezonefileorupdatedvia
17 dynamicupdate.Enterprisesshouldfollowanyestablishedprocedure.

18 H.2 DNS Authority


19 LikeDNSSigner,above,thereisnodifferencebetweenastandardsetupoftheauthoritative
20 server,andanauthoritativeserverthathostsDANERRtypes.Secure64usersshouldconsult
21 theirproductdocumentationonhowtosetupaDNSAuthorityinstance.

22 H.3 DNS Cache


23 LikeDNSSignerandDNSAuthority,therearenotadditionalstepsinconfiguringaDNSCache
24 instanceforsupportingDANE.However,DANErequirestheuseofDNSSECvalidation,soDNS
25 Cacheadministrators(i.e.thosethatcanenablethecachdnsadminrole)mustenableDNSSEC
26 validationandinsurethattheDNSCachehasasetofinitialtrustanchors.

DNS-Based Email Security Practice Guide


DRAFT 144