idnits 2.17.1 draft-thomson-tls-acp-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 6, 2014) is 3694 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-09 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-09 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track March 6, 2014 5 Expires: September 7, 2014 7 Authenticated Content Promise Extension for (D)TLS 8 draft-thomson-tls-acp-00 10 Abstract 12 This document describes an extension to Transport Layer Security 13 (TLS) and Datagram TLS (DTLS) that enables the negotiation of a 14 promise to protect session content from modification and 15 eavesdropping by third parties. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 7, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Authenticated Content Promise . . . . . . . . . . . . . . 3 53 1.2. Conventions and Terminology . . . . . . . . . . . . . . . 3 54 2. Authenticated Content Promise . . . . . . . . . . . . . . . . 3 55 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 60 6.2. Informative References . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 WebRTC [I-D.ietf-rtcweb-overview] creates a new understanding of the 66 way that "user-generated content" is used on the world wide web. The 67 established definition identifies content that is generated by users 68 and used by sites; after all, the primary mode of interaction on the 69 web is between users and sites. 71 WebRTC changes that by enabling users to communicate directly, with 72 secure channels between established between user agents (or 73 browsers). These channels might be established with the aid of a web 74 site, but the content of the communication session can be made 75 inaccessible to the site [I-D.ietf-rtcweb-security-arch]. With peer 76 authentication, each user is able to be sure that: 78 o the content they are generating is only accessible to the 79 authenticated peer; and 81 o the content they are receiving can be attributed solely to the 82 authenticated peer. 84 On the originating end of a communications session, this guarantee is 85 easy to provide. A web site is able to provide instructions for 86 session setup that allow the browser to protect content from the 87 site, and to restrict where content is delivered based on identity. 89 On the receiving side, this is more complicated. Since there is a 90 desire to enable use cases where sites do have access to content that 91 is received, there is a need for a signal of some form to distinguish 92 the cases. 94 It is possible to use the WebRTC signaling channel for this purpose, 95 but only with restrictions. The signaling channel is considered 96 untrustworthy, so additional protection would be required to ensure 97 that any indicators could not be erased or re-attributed to other 98 keying material. Furthermore, this would also require protection 99 against replay. Prohibiting key reuse between confidential and non- 100 confidential sessions would suffice for this purpose, though this is 101 undesirable for other reasons. 103 1.1. Authenticated Content Promise 105 This document describes a Transport Layer Security (TLS) [RFC5246] 106 extension, which, if negotiated, establishes a session as being 107 confidential. Peers that negotiate this extension promise that: 109 o Any content that is written to or read from the connection MUST be 110 protected from modification by entities other than the one that is 111 authenticated (i.e., the user). 113 o Any content that is written to or read from the connection MUST 114 NOT be recorded or forwarded to any entity other than the one that 115 is authenticated. 117 In addition to establishing an authenticated channel for 118 communications, this provides a key advantage over signaling-based 119 methods for ensuring privacy. Key continuity is possible, which 120 allows clients to operate without identity providers and still have a 121 stable basis for establishing continuity of identity with peers. 123 1.2. Conventions and Terminology 125 At times, this document falls back on shorthands for establishing 126 interoperability requirements on implementations: the capitalized 127 words "MUST", "SHOULD" and "MAY". These terms are defined in 128 [RFC2119]. 130 2. Authenticated Content Promise 132 A new extension type ("authenticated_content_promise(TBD)") is 133 defined. If this extension is negotiated, both client and server are 134 bound by a promise to protect content. 136 enum { 137 authenticated_content_promise(TBD), (65535) 138 } ExtensionType; 140 The "extension_data" field of this extension MUST be empty. 142 3. Security Considerations 144 Endpoints need to take care to avoid rendering of authenticated 145 content alongside other content in a way that could cause user 146 confusion equivalent to the effect of modifying content. For 147 instance, unauthenticated audio could be played at higher volume 148 levels than authenticated audio, potentially misleading users about 149 what sounds can be attributed to each. 151 This looks a little like digital rights management (DRM), but it 152 really doesn't promise to protect content to the degree required by 153 DRM schemes. It relies solely on users and their trust each other 154 (and their user agents, operating system and hardware). Nothing in 155 this mechanism stops a compromised end system from modifying or 156 eavesdropping on communications, from information being overhead or 157 seen by people nearby, or from any action taken on the part of the 158 authentiated entities, such as screen recording. 160 A little care is needed to avoid side channels, some of which are 161 quite obvious. For example, even with echo cancellation, audio 162 played over speakers can be picked up by nearby microphones; video 163 playback might be observable in a mirror. 165 4. IANA Considerations 167 IANA has allocated a TLS extension code point of (TBD) for this 168 extension. 170 5. Acknowledgements 172 Eric Rescorla helped identify the problem and formulate this 173 mechanism. 175 6. References 177 6.1. Normative References 179 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 180 Requirement Levels", BCP 14, RFC 2119, March 1997. 182 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 183 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 185 6.2. Informative References 187 [I-D.ietf-rtcweb-overview] 188 Alvestrand, H., "Overview: Real Time Protocols for Brower- 189 based Applications", draft-ietf-rtcweb-overview-09 (work 190 in progress), February 2014. 192 [I-D.ietf-rtcweb-security-arch] 193 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 194 rtcweb-security-arch-09 (work in progress), February 2014. 196 Author's Address 198 Martin Thomson 199 Mozilla 200 Suite 300 201 650 Castro Street 202 Mountain View, CA 94041 203 US 205 Email: martin.thomson@gmail.com