idnits 2.17.1 draft-smtp-dane-dmarc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 10, 2019) is 1781 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6698' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC7489' is defined on line 300, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7489 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 UTA R. Mukhia 3 Internet-Draft B. Rajendran 4 Intended status: Standards Track BS. Bindhumadhava 5 Expires: December 12, 2019 CDAC Bangalore 6 June 10, 2019 8 An approach for end-to-end Email Security with DANE and DMARC 9 draft-smtp-dane-dmarc-00 11 Abstract 13 An end-to-end email security solution is proposed by implementing 14 both DANE and DMARC protocols. DMARC enables the recipient's mail 15 server, with a method to verify the sender's ingenuity. DANE intends 16 to mitigate the MITM attack, by enabling the sender a method to 17 authenticate the recipient's mail domain. DANE and DMARC therefore 18 complement each other by allowing the sender to verify the 19 recipient's domain, and the recipient to verify the sender's address 20 respectively. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 12, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Architecture of DANE with DAMRC for secure Email . . . . . . 3 58 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 5. Normative References . . . . . . . . . . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 SMTP is a hop-by-hop mechanism. For a long time now, email servers 66 have had the option of using TLS to transparently encrypt the message 67 transmission from one server to other. Use of TLS with SMTP,when 68 available ensures that the message content are secured during 69 transmission between the servers.But not all servers support TLS.Some 70 of the reasons many email providers doesn't support TLS are 72 1. Purchase of one or more SSL certificates is not done 74 2. Configuration of the email servers to use them (and keep these 75 configurations updated)is not done 77 3. Allocation of additional computational resources on the email 78 servers is not involved 80 There are some issues from sending computers or servers also like, 81 They never use TLS or They use TLS if receiver side is also using it 82 otherwise sends insecurely or They use TLS otherwise doesn't deliver 83 at all. 85 Now comes the point that actually how secure is SMTP TLS.TLS protects 86 the transmission of the content of the email messages,but it doesn't 87 do anything for protecting the security of the message before it is 88 sent or after it arrives at its destination .And for that, other 89 encryption mechanisms are required.There are many reasons to say SMTP 90 TLS doesn't provide end-to-end security.As there is no mandatory 91 support for SSL/TLS in the email system. 93 A receiver's support of the SMTP TLS can be removed by a Man-in-the- 94 middle. In such cases opportunistic TLS will deliver messages 95 securely and forced TLS will not deliver the message.If any aspect of 96 the TLS negotiation is garbled,then encryption is not used. It is 97 very easy for a man-in-the-middle to inject garbage into the TLS 98 handshake(which is done in clear text ) and have the connection 99 downgraded to plain text(opportunistic TLS) or have the connection 100 forced(forced TLS).Even when the SMTP TLS is offered and accepted,the 101 certificate presented during the TLS handshake is usually not checked 102 to see if it is really for the expected domain and unexpired.Most 103 MTA's offer self signed certificates, therefore in many cases one has 104 an encrypted channel to an unauthenticated MTA, which can only 105 prevent passive eavesdropping. 107 To mitigate the mentioned problems with SMTP TLS, DANE and DMARC can 108 be used with SMTP.DANE prevents middle man by giving sender a method 109 secured using DNSSEC,it ensures that message goes only to the 110 receiver.This is done when key provided by receiver's mail exchanges 111 matches with the key he has authorized in DNS to receive mail for his 112 domain. 114 Phishing is a very common type of threat,it can be avoided if DMARC 115 is implemented, as both DKIM and SPF are part of DMARC.It is job of 116 DKIM to authenticate the domain that affixed the signature of the 117 message.Therefore DMARC intends to mitigate the threat of arbitrary 118 sender. 120 As we know,SMTP is not designed keeping sender in mind,attacker can 121 easily connect to receiver's mail server and send him email appearing 122 to be coming from sender.In this case,DMARC provides the solution by 123 giving receiver mail server a method to verify that the sender is 124 genuine and this is done via two methods either via cryptographic 125 signature using DKIM or via IP ACL using SPF.So DANE and DMARC are 126 complimentary to each other, DANE ensures that the correct receiver 127 receives the message while the messages are correctly encrypted in 128 the transit and DMARC makes sure that messages are coming from 129 legitimate sender. 131 2. Architecture of DANE with DAMRC for secure Email 133 1. The sender creates a message. 135 2. SHA-256 is used to generate a 256-bit message digest of the 136 message. The combination of SHA-256 and RSA provides an 137 effective digital signature scheme. Because of the strength of 138 RSA, the recipient is assured that only the possessor of the 139 matching private key could have generated the signature. 140 Because of the strength of SHA-256, the recipient is assured 141 that no one else could generate a new message that matches the 142 hash code and, hence, the signature of the original message. 144 3. The message digest is encrypted with RSA using the sender's 145 private key, and the result is appended to the message. 147 4. DNS Based Authentication of Named Entities(DANE) offers the 148 option to use the DNSSEC infrastructure to store and sign keys 149 an certificates that are used by TLS. This is to avoid a 150 condition when many number of CA's are compromised then the 151 attacker can obtain the private key of the CA, issues 152 certificates under a false name, or introduce new bogus root 153 certificates into a root certificate store.There is no 154 limitation of scope for the global PKI, and a compromise of a 155 single CA can damage the integrity of the entire PKI system. 157 5. Domain Keys Identified Mail (DKIM) permits a person,role,or 158 organization that owns the signing domain to claim some 159 responsibility for a message by associating the domain with the 160 message.The domain can be an author's organization,an 161 operational relay,or one of their agents.Responsibility is 162 validated through a cryptographic signature and by querying the 163 signer's domain directly to retrieve the appropriate public key 164 which is provided to the receiving MTA. 166 6. DMARC works with SPF and DKIM.SPF enables senders to advise 167 receivers, via DNS, whether mail purporting to come from the 168 sender is valid, and whether it should be delivered, flagged, or 169 discarded. DKIM authenticates the domain that affixed a 170 signature to the message. SPF focuses on the SMTP envelope. 171 DMARC requires that the From address match (be aligned with) an 172 Authenticated Identifier from DKIM or SPF. In the case of DKIM, 173 the match is made between the DKIM signing domain and the From 174 domain. In the case of SPF, the match is between the SPF- 175 authenticated domain and the From domain. 177 7. Signature is then passed onto the receiving MTA then to the MUA 178 and following steps take place. 180 8. TLSA, DNS record type, which can be used for a secure method of 181 authenticating Secure Sockets Layer/Transport Layer Security 182 (SSL/TLS) certificates. The TLSA provides for: 184 1. Specifying constraints on which CA can vouch for a 185 certificate, or which specific PKI end-entity certificate is 186 valid. 188 2. Specifying that a service certificate or a CA can be 189 directly authenticated in the DNS itself 191 The TLSA RR enables certificate issue and delivery to be tied to 192 a given domain. A server domain owner creates a TLSA resource 193 record that identifies the certificate and its public key. When 194 a client receives an X.509 certificate in the TLS negotiation, 195 it looks up the TLSA RR for that domain and matches the TLSA 196 data against the certificate as part of the client's certificate 197 validation procedure. 199 9. The receiver uses RSA with its private key to decrypt and 200 recover the content-encryption key. 202 10. The content-encryption key is used to decrypt the message. 204 3. IANA Considerations 206 This memo includes no request to IANA. 208 4. Security Considerations 210 The security of the DNS RRtype relies on the security of DNSSEC to 211 verify that the TLSA record has not been altered. A better design 212 for authenticating DNS would be to have the same level of 213 authentication used for all DNS additions and changes for a 214 particular domain name.DNSSEC forms certificates(the binding of an 215 identity to a key) by combining a DNSKey,DS or DLV resource record 216 with an associate RRSIG record.These records then form a signing 217 chain extending from the clients trust anchors to the RR of interest. 218 The risk that a given certificate that has a valid signing chaining 219 fake is related to the number of keys that can contribute to the 220 validation of the certificate the quality of protection each private 221 key receives,the value of each key to an attacker and the value of 222 falsifying the certificate. 224 DNSSEC allows any set of domains to be configured as trust anchors 225 and/or DLVs, but most clients are likely to use the root zone as 226 their only trust anchor.Also because a given DNSKey can only sign 227 resources record for that zone,the number of private keys capable of 228 compromising a given TLSA resource record and the nearest trust 229 anchor,plus any configured DLV Domains.Typically this will be six 230 keys,half of which will be KSKs. KSK is stored off-line and 231 protected more carefully than the ZSK,but not all the domains do so. 232 The Security applied to a zone's DNSKey should be proportional to the 233 value of domain,but that is difficult to estimate.For Example the 234 root DNSKey has protections and controls comparable to or exceeding 235 those of public CAs.On the other hand,small domain might provide no 236 more protection to their keys than they do to their other data.DNSKey 237 are limited in what they can sign ,so a compromise of the DNSKey 238 for"example.com" provides no avenue of attack against 239 "example.org".Therefore the impact of a compromise of.Com's DNSKey 240 ,while considerable would be limited t .com domains. 242 Public CAs are not typically constrained in what names they can sign 243 and therefore a compromise of even one CA allows the attacker to 244 generate a certificate for any name in the DNS. Since TLSA 245 certificate association is constrained to it's associated 246 name,protocol and port,the PKIX certificate is similarly 247 constrained,even if it's public CAs signing the certificate(if any) 248 or not.If public CA is compromised,only the victim will see the 249 fraudulent certificate.Implementation of DANE rely heavily on the DNS 250 ,and therefore is prone to security attacks based on the deli berate 251 mis-association of TLSA records and DNS names.The connection between 252 TLSA records and DNS name should rely on DNS resolver,rather than 253 depending on caching result of previous domain name lookups ,also it 254 should depend on the TTL of that lookup,if it is more then only the 255 information will be useful otherwise not.If this part is not taken 256 care of then it can fall the victim of spoofing,having access denied 257 when a previously accessed servers TLSA record changes,such as during 258 a certificate rollover.Even with secure communications between a host 259 and the external validating resolver,there is a risk that the 260 external validator could become compromised.Nothing prevents a 261 compromised external DNSSEC validator from claiming that all the 262 records it provides are secure,even is the data is falsified unless 263 the client checks the DNSSEC data itself.For this reason DNSSEC 264 validation is best performed, on-host even when a secure path to an 265 external validator is available. 267 In DMARC, URI is a format by which a domain owner specifies the 268 destination for the two report types that are supported.Receivers may 269 impose a limit on the number of URIs to which they will send 270 reports,they must support the ability to send to at least two.DMARC 271 and it's underlying techniques SPF and DKIM depend on the security of 272 the DNS.To avois DNS-based exploits,the deployment of DNSSEC should 273 be done parallel with the deployment of DMARC by both domain owners 274 and mail receivers. A common attack in messaging abuse is the 275 presentation of false information in the display name portion of the 276 "FROM" field.This takes place when it is possible for the email 277 address in that field to be an arbitrary address or domain name,while 278 containing a well known name( a celebrity,company,eole etc.) in the 279 display name to fool th receiver. This attack is based on the habit 280 of common MUAs that they show the display name and not the email 281 address when both are available. If email address is found with 282 display name,execute the DMARC mechanism of the domain name found 283 there rather than the domain name discovered before.but spoofers can 284 cause the attack by simply not using an email address in the display 285 name ,So this doesn't solve the problem.In the MUA display name 286 should be shown only if the DMARC mechanism succeeds. This is also 287 easily defeated,the attacker can use another domain name in the 288 display name to pass the DMARC Test.In the MUA,the display name 289 should be shown if the DMARC mechanism passes and the email address 290 thus validated matches one found in the receiving user's list of 291 known addresses. 293 5. Normative References 295 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 296 of Named Entities (DANE) Transport Layer Security (TLS) 297 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 298 2012, . 300 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 301 Message Authentication, Reporting, and Conformance 302 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 303 . 305 Authors' Addresses 307 Ranjana 308 CDAC Bangalore 309 Bangalore 310 India 312 Email: ranjana@cdac.in 314 Balaji Rajendran 315 CDAC Bangalore 316 Bangalore 317 India 319 Email: balaji@cdac.in 321 Bindhumadhava BS 322 CDAC Bangalore 323 Bangalore 324 India 326 Email: bindhu@cdac.in