idnits 2.17.1 draft-hallambaker-consent-00.txt: -(36): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(192): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 391 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' introduction. It must be possible for a mailing list to' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([ListSpec], [RFC2369]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7217 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) -- Missing reference section? 'RFC2369' on line 385 looks like a reference -- Missing reference section? 'ListSpec' on line 387 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P. Hallam-Baker 3 Internet Draft VeriSign Inc. 4 Document: draft-hallambaker-consent-00.txt July 2004 5 Expires: October 2005 7 Proof of Consent Mechanism 9 Status of this Memo 11 This document is an Internet-Draft and is NOT offered in 12 accordance with Section 10 of RFC2026, and the author 13 does not provide the IETF with any rights other than to 14 publish as an Internet-Draft 16 Internet-Drafts are working documents of the Internet 17 Engineering Task Force (IETF), its areas, and its 18 working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum 22 of six months and may be updated, replaced, or obsoleted 23 by other documents at any time. It is inappropriate to 24 use Internet-Drafts as reference material or to cite 25 them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be 30 accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 We propose a mechanism Proof of Consent that allows an 36 email recipient to provide verifiable proof of �opt-in� 37 consent to receive email. Proof of Consent may be used 38 to automatically whitelist email from mailing lists and 39 email forwarded from another email server. 41 Proof of Consent is designed to require minimal state 42 maintenance by both the email sender and the recipient 43 and to be deployable with minimal impact on existing 44 email infrastructure. 46 1. Requirements 48 The Proof of Consent mechanism provides a verifiable and 49 revocable proof that a recipient consented to receive 50 email from a specified source. It is designed to address 51 several of the existing problems of maintaining mailing 52 lists and other consent based bulk mail such as 53 newsletters and solicited advertisements. 55 We note that other protocols such as Really Simple 56 Syndication (RSS) and Network News Transport Protocol 57 (NNTP) offer facilities that are similar to mailing lists 58 without the need for a proof of consent mechanism. 59 Despite the existence of these mechanisms email remains 60 the most commonly used means of obtaining data of this 61 type and it is appropriate to address these requirements 62 in the context of email mailing lists despite the 63 existence of alternative protocols that already meet 64 them. 66 1.1 Subscription Consent Problem 68 The SMTP protocol does not provide a means to allow a 69 mail server receiving a message alleged to have been sent 70 to a mailing list message to determine whether it was 71 solicited or not. 73 1.2 Reputation Attacks 75 An SMTP mail server may be falsely accused of having sent 76 messages to a non-subscriber. 78 As the situation currently stands there is no way to 79 determine the truth or falsehood of such allegations. A 80 party may even sign up for a newsletter with opposing 81 views so as to be able to complain about the messages 82 sent and hope to cause the mailing list to be put on a 83 blacklist. 85 Events of this type have occurred in connection with 86 mailing lists of every political persuasion. When 87 complaints are made about a blacklisting they are 88 typically met with further hearsay accusations that the 89 accused was �notorious�. 91 1.3 Unsubscribe Problem 93 Mailing list users often find it difficult to 94 unsubscribe. In many cases requests to be unsubscribed 95 are sent to the entire list. 97 The un-subscription problem can be a serious problem when 98 an intermediary such as a mailing list gateway is 99 involved. 101 Users often fail to unsubscribe from mailing lists, 102 causing huge volumes of mail to accumulate unread in an 103 unused account or an unread mail folder. In some cases 104 the subscribed email account is also abandoned. 106 Often a mail user will subscribe to a mailing list on a 107 speculative basis and find that they do not read the list 108 often. 110 1.5 Abandoned List Problem 112 Mailing lists are often created and then abandoned after 113 a period of time after falling into disuse. This can 114 create serious problems if a spammer after discovers an 115 abandoned list without an administrator and starts to 116 send messages to the list. 118 1.6 Maintenance Problem 120 The management of a high volume mailing list requires a 121 considerable amount of effort, largely because of the 122 need to manage the problems of subscribers who are unable 123 to unsubscribe, have abandoned subscriptions etc. Another 124 increasing concern for mailing list administrators is 125 that their lists may be blocked by blacklists, often 126 through no fault of their own due to reputation attacks. 128 2. Deployment Constraints 130 The deployed email infrastructure is the result of more 131 than twenty years of development, much of which has taken 132 place in an ad-hoc fashion. As such it is vital that any 133 proposal to change that infrastructure be compatible with 134 the infrastructure as deployed and not merely as it is 135 described in theoretical specifications. 137 2.1 SMTP Deployment Limitations 139 Many SMTP servers are poorly configured and perform 140 arbitrary and in many cases capricious modifications to 141 messages as they are transmitted. 143 2.2 SMTP Client Limitations 144 features offered by mail readers have not changed 145 significantly in the past five years, basic principles of 146 mail delivery have been unchanged for almost ten years. 147 As a result few end users are likely to upgrade their 148 mail client in order to be able to take advantage of a 149 protocol meeting the requirements described. 151 2.3 Separate Servers for Incoming and Outgoing Mail 153 Enterprises are increasingly using separate mail servers 154 for incoming and outgoing mail. Even if the end user 155 interacts with a single server it is likely that incoming 156 mail will be pre-processed by some form of mail proxy, 157 particularly if anti-spam filtering is being performed. 159 2.4 Network Protocol Access Limitations 161 Many ISPs limit or block completely use of certain 162 Internet protocols. These blocks may be imposed for a 163 variety of reasons that include preventing spam, service 164 differentiation and caprice. 166 2.5 Existing Features Insufficiently Observed 168 Many of the problems with mailing lists could be 169 addressed by simply deploying the existing proposals in 170 [RFC2369]. These provide a mechanism that allows mailing 171 lists to use URIs to specify how users can perform 172 functions unsubscribe from a list. 174 A header of particular interest in this specification is 175 the Mailing-List header that uniquely identifies a 176 mailing list. 178 3. The Proof of Consent Protocol 180 The chief deficiency in the email protocols with respect 181 to the requirements is that an incoming mail server has 182 no means of determining whether a recipient did 183 legitimately consent to opt-in. 185 Most mailing list applications support the use of a 186 challenge/response protocol to verify subscription 187 requests. The mailing list sends the subscriber a 188 challenge token consisting of a string of characters. To 189 the token to the mailing list. 191 The Proof of Consent mechanism proposes the use of a 192 second token that is created by the subscriber�s incoming 193 mail server and forwarded together with the challenge 194 token to the mailing list. The mailing list then includes 195 a copy of the token in every email message sent to 196 provide the proof that it was solicited. 198 This mechanism minimizes the need for state maintenance 199 at each stage in the mail transfer protocol, avoiding the 200 need for additional per user records to be stored at 201 either the incoming or outgoing servers. 203 3.1 Initialization 205 The incoming mail server establishes a shared secret k. 206 In the case that there are multiple incoming servers the 207 shared secret may be established manually or by means of 208 some form of key agreement protocol using public key 209 based credentials. 211 Once established, the shared secret is maintained for an 212 extended time period such as a year. Incoming mail 213 servers must keep a record of all shared secrets that 214 have ever been used and the validity intervals in which 215 they were used. 217 3.2 Confirmation Code 219 During the subscription process we establish a 220 confirmation code that is cryptographically bound to the 221 mailing list name, the recipient email address and the 222 date of subscription by means of the shared secret: 224 Code = MAC (mailing-list, recipient, date) 226 Where: 228 list 229 The string the mailing list will use in the 230 Mailing-List header 231 recipient 232 The email address of the recipient 233 date 234 The day on which the subscription took place. 236 Each message sent from the mailing list contains a 237 Confirmation-Code header as follows: 239 Confirmation-Code: 241 The mailing list already needs to maintain a per- 242 subscriber record of mailing addresses. The additional 243 state required to support the confirmation code protocol 244 is negligible. 246 We require the subscription date to be stored explicitly 247 for two reasons, first it requires the mailing list 248 administrator to take notice of the age of subscriptions, 249 secondly it allows the incoming mail server to reject 250 mail with a stale confirmation code that is many years 251 old. This allows a mail server to reject mail sent to a 252 mailing list that a previous holder of an account name 253 subscribed to. 255 The incoming mail server can authenticate a confirmation 256 code (but not the attached message) by means of the 257 shared secret. Note that it is not necessary for the MAC 258 algorithm to be standardized, it is sufficient for the 259 sender and receiver to use the same one. 261 3.3 Subscription Process 263 The confirmation code is generated during the 264 subscription process and communicated to the mailing list 265 server. 267 We assume that any subscription process involves a 268 confirmation process by means of an email callback loop 269 challenge. The incoming mail server detects a mailing 270 list request for subscription confirmation and causes it 271 to be redirected so that the appropriate confirmation 272 code can be added. 274 The callback loop challenge contains a new header 275 constructed as follows: 277 Challenge-Code: 279 Where 280 The string the mailing list will use in the 281 Mailing-List header 282 recipient 283 The email address of the recipient 284 opaque 285 An opaque code defined by the mailing list 286 confirmation server to be used for confirmation 287 purposes. 289 If the user responds to the confirmation request the 290 appropriate challenge code is generated and forwarded to 291 the indicated address along with the opaque code to 292 establish that the user did intend to subscribe. 294 3.4 Legacy Subscriptions 296 The confirmation code protocol must support gradual 297 introduction. It must be possible for a mailing list to 298 deploy the protocol without having to re-subscribe 299 existing users. It would be advantageous if this can be 300 achieved in such a way that allows a mailing list 301 administrator to be able to deploy the protocol 302 incrementally and still be able to establish that 303 unsolicited messages are never sent. 305 When a mailing list server sends a message to a legacy 306 subscriber the confirmation-code header is still present 307 but only the date field is filled, the confirmation field 308 is absent. This alerts the incoming server to the fact 309 that the message is purported to be a legacy 310 subscription. 312 If the incoming server supports the confirmation code 313 protocol it may query the user to determine whether the 314 subscription is actually authorized and if so provide the 315 relevant confirmation code to the mailing list server to 316 avoid the need for subsequent authorizations. 318 A similar procedure may be employed when the confirmation 319 code protocol is deployed on an existing incoming mail 320 server. In this case it is recommended that the service 321 provide some mechanism to allow the user to send 322 confirmation codes to a group of mailing lists at the 323 same time. 325 malicious allegations by having a copy of the mailing 326 list signed by a digital notary at the time the protocol 327 is deployed. The signature format may be chosen in such a 328 way that validity of each entry in the list may be 329 determined independently without revealing any 330 information about any other list member. Various schemes 331 suggest themselves including use of Merkle hash trees or 332 the XML Signature manifest object. It is recommended that 333 any mechanism chosen use a random mask value within each 334 entry to prevent attackers from finding out that a 335 specified party has subscribed to a list. 337 This information could be made available through some 338 form of protocol, however it is likely that requiring 339 existing users to re-subscribe will prove more 340 attractive. 342 3.5 Revocation of Confirmation Codes 344 The mechanism described only provides for the 345 authenticity of subscription requests to be established. 346 No assurance is provided for un-subscription requests, 347 nor is the protocol easily modified to achieve this 348 directly. 350 The confirmation code is cryptographically bound to the 351 mailing list identifier. An incoming mail server or spam 352 filtering application can filter incoming mail on the 353 basis of the mailing list identifier. Although this 354 requires the service to maintain state the overhead is 355 minimal and saves considerable resources in the long run. 356 A mailing list may choose not to observe requests to 357 unsubscribe but there is no incentive to do so if the 358 messages are unlikely to be read. 360 4. Security Considerations 362 4.1 Replay Attack 364 The consent to receive mechanism provides proof that the 365 recipient of an email message has consented to receive 366 messages from a specified source. It does not provide 367 definitive proof that a particular message originates 368 from the source specified. 370 recipient/sender combination can generate an arbitrary 371 volume of messages containing the token. 373 This vulnerability is unlikely to represent a significant 374 risk in the context of spam mitigation. It is highly 375 unlikely that a spammer could obtain a sufficiently large 376 number of consent tokens to make bulk distribution of 377 spam through this mechanism feasible. 379 The vulnerability may be eliminated through use of the 380 consent token mechanism in combination with an 381 authentication mechanism. 383 References 385 [RFC2369] http://www.ietf.org/rfc/rfc2369.txt 387 [ListSpec] http://www.nisto.com/listspec/ 389 Copyright Statement 391 Copyright (C) The Internet Society (year). This document 392 is subject to the rights, licenses and restrictions 393 contained in BCP 78, and except as set forth therein, the 394 authors retain all their rights." 396 "This document and the information contained herein are 397 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 398 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 399 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 400 FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 401 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 402 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 403 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 404 PARTICULAR PURPOSE." 406 Author's Addresses 408 Phillip Hallam-Baker 409 VeriSign Inc. 410 Email: pbaker@verisign.com