idnits 2.17.00 (12 Aug 2021) /tmp/idnits31406/draft-kucherawy-reputation-query-dns-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 1, 2011) is 4000 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Borenstein 3 Internet-Draft Mimecast 4 Intended status: Informational M. Kucherawy 5 Expires: December 3, 2011 Cloudmark 6 June 1, 2011 8 Reputation Data Interchange using the DNS 9 draft-kucherawy-reputation-query-dns-00 11 Abstract 13 This document defines a mechanism to conduct queries for reputation 14 information using the Domain Name System. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 3, 2011. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Document Series . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Terminology and Definitions . . . . . . . . . . . . . . . . . . 3 53 3.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.2. Other Definitions . . . . . . . . . . . . . . . . . . . . . 3 55 4. Description . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Query Format . . . . . . . . . . . . . . . . . . . . . . . 4 57 4.2. Reply Format . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Public Discussion . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 This memo defines a method to query a reputation data service for 70 information about an entity, using the Domain Name System (DNS). It 71 is part of a series defining the overall reputation query/response 72 structure as well as the concept of reputation "vocabularies" for 73 particular applications. 75 2. Document Series 77 This memo represents the media type registration, part of a series of 78 documents that define the overall service and introduce the initial 79 exemplary applications. The series is as follows: 81 1. RFCxxxx: A Model for Reputation Interchange 83 2. RFCxxxx+1: A Media Type for Reputation Information 85 3. RFCxxxx+2: Using UDP for Reputation Interchange 87 4. RFCxxxx+3: Using the DNS for Reputation Interchange (this memo) 89 5. RFCxxxx+4: Using HTTP/XML for Reputation Interchange 91 6. RFCxxxx+5: A Reputation Vocabulary for Email Identity Reputation 93 7. RFCxxxx+6: A Reputation Vocabulary for Email Property Reputation 95 3. Terminology and Definitions 97 This section defines terms used in the rest of the document. 99 3.1. Keywords 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [KEYWORDS]. 105 3.2. Other Definitions 107 Other terms of importance in this memo are defined in RFCxxxx, the 108 base memo in this document series. 110 4. Description 112 The [DNS] provides a distributed, fault-tolerant, extensible database 113 generally used for retrieving information about services and hosts on 114 the Internet. In the recent past its ability to store arbitrary text 115 data to support various applications has been exploited to store such 116 information as [DKIM] keys, expressions of policy such as [ADSP] and 117 [SPF], or indications of group membership such as [VBR]. This memo 118 defines another such application. 120 In line with [DNS-EXPAND], the TXT resource record type is used for 121 this application. 123 4.1. Query Format 125 When constructing the name to be queried, the following steps are 126 followed: 128 1. Present the subject of the reputation query, formed per the 129 particular reputation application's rules, to the [SHA1] 130 algorithm, producing a 20-byte blob of binary output. 132 2. Convert the binary output to a printable ASCII string by 133 expressing each byte, in order, as a two-digit hexadecimal 134 string. Output this string. 136 3. Append an ASCII period (0x2E). 138 4. Append either the name of the assertion of interest, defined by 139 the particular reputation application's rules, or the string 140 "_any" (ASCII 0x5F, 0x61, 0x6E, 0x79) if all available 141 assertions are being requested. 143 5. Append an ASCII period (0x2E). 145 6. Append the name of the reputation application within which a 146 query is being made. This name MUST be one registered with 147 IANA. 149 7. Append an ASCII period (0x2E). 151 8. Append the string "_rep" (ASCII 0x5F, 0x72, 0x65, 0x70). 153 9. Append an ASCII period (0x2E). 155 10. Append the domain name that constitutes the root of the DNS sub- 156 tree at which the reputation data are available. This is the 157 "base" of the reputation service. 159 For example, suppose a client wishes to ask for any information the 160 reputation service at "example.com" has about "example.net" within 161 the context of the "email-id" application. A hex-converted SHA1 hash 162 of "example.net" is the string 163 "c15fd3911e2d2a6ed98d884447782ad67fdba939". The query would be: 165 c15fd3911e2d2a6ed98d884447782ad67fdba939._any.email._rep.example.com 167 The hash is done to allow arbitrarily long subjects to be encoded 168 into the name of a DNS query. 170 4.2. Reply Format 172 The reply is formatted as one or more TXT resource records. Replies 173 not of type TXT MUST be ignored. 175 The client MUST decode the TXT reply by concatenating all character- 176 string (see Section 3.3 of [DNS] payloads (i.e., drop all length 177 bytes) into a single composite string. The resultant string is 178 expected to be of the following form, expressed in [ABNF]: 180 rep-result := rep-assertion SP rep-value SP rep-data *rep-extension 182 rep-assertion := token 184 rep-extension := SP token ":" token 186 rep-value := ("0" / "1") [ "." 1*4DIGIT ] 187 ; MUST be between 0 and 1 inclusive 189 rep-data := 1*20DIGIT 191 "token" is imported from [MIME]. 193 When the query was not about a specific assertion within the context 194 of the reputation application, and thus "_any" was used, multiple TXT 195 records MAY be returned, each indicating its own assertion. 197 Assertions and vocabulary extensions not registered as part of the 198 reputation application in use MUST be ignored. 200 5. IANA Considerations 202 This memo presents no actions for IANA. 204 6. Security Considerations 206 This memo describes security considerations introduced by the media 207 type defined here. 209 6.1. General 211 This memo is part of a series introducing a reputation query and 212 response system (see Section 2). The Security Considerations 213 sections of the other memos should also be consulted. 215 7. References 217 7.1. Normative References 219 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 220 Specifications: ABNF", STD 68, RFC 5234, January 2008. 222 [DNS] Mockapetris, P., "Domain names - implementation and 223 specification", STD 13, RFC 1035, November 1987. 225 [KEYWORDS] 226 Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, March 1997. 229 [SHA1] U.S. Department of Commerce, "Secure Hash Standard", 230 FIPS PUB 180-2, August 2002. 232 7.2. Informative References 234 [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, 235 "DomainKeys Identified Mail (DKIM) Author Domain Signing 236 Practices (ADSP)", RFC 5617, August 2009. 238 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 239 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 240 Signatures", RFC 4871, May 2007. 242 [DNS-EXPAND] 243 Falstrom, P., Ed., Austein, R., Ed., and P. Koch, Ed., 244 "Design Choices When Expanding the DNS", RFC 5507, 245 April 2009. 247 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 248 Extensions (MIME) Part One: Format of Internet Message 249 Bodies", RFC 2045, November 1996. 251 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 252 for Authorizing Use of Domains in E-Mail, Version 1", 253 RFC 4408, April 2006. 255 [VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 256 Reference", RFC 5518, April 2009. 258 Appendix A. Public Discussion 260 Public discussion of this suite of memos takes place on the 261 domainrep@ietf.org mailing list. See 262 https://www.ietf.org/mailman/listinfo/domainrep. 264 Authors' Addresses 266 Nathaniel Borenstein 267 Mimecast 268 203 Crescent St., Suite 303 269 Waltham, MA 02453 270 USA 272 Phone: +1 781 996 5340 273 Email: nsb@guppylake.com 275 Murray S. Kucherawy 276 Cloudmark 277 128 King St., 2nd Floor 278 San Francisco, CA 94107 279 USA 281 Phone: +1 415 946 3800 282 Email: msk@cloudmark.com