idnits 2.17.1 draft-ietf-kitten-tls-channel-bindings-for-tls13-03.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5802, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC8446, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 March 2021) is 1131 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Layer Security S. Whited 3 Internet-Draft 15 March 2021 4 Updates: 5802, 8446 (if approved) 5 Intended status: Standards Track 6 Expires: 16 September 2021 8 Channel Bindings for TLS 1.3 9 draft-ietf-kitten-tls-channel-bindings-for-tls13-03 11 Abstract 13 This document defines a channel binding type, tls-exporter, that is 14 compatible with TLS 1.3 in accordance with RFC 5056, On Channel 15 Binding. 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 https://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 16 September 2021. 34 Copyright Notice 36 Copyright (c) 2021 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 (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 52 2. The 'tls-exporter' Channel Binding Type . . . . . . . . . . . 2 53 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 54 3.1. Use with Legacy TLS . . . . . . . . . . . . . . . . . . . 3 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Registration of Channel Binding Type . . . . . . . . . . 3 57 4.2. Registration of Channel Binding TLS Exporter Label . . . 4 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 60 5.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 The "unique" channel binding types defined in [RFC5929] were found to 66 be vulnerable to the "triple handshake vulnerability" 67 [TRIPLE-HANDSHAKE] without the extended master secret extension 68 defined in [RFC7627]. Because of this they were not defined for TLS 69 1.3 (see [RFC8446] section C.5). To facilitate channel binding with 70 TLS 1.3, a new channel binding type is needed. 72 1.1. Conventions and Terminology 74 Throughout this document the acronym "EKM" is used to refer to 75 Exported Keying Material as defined in [RFC5705]. 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 79 "OPTIONAL" in this document are to be interpreted as described in BCP 80 14 [RFC2119] [RFC8174] when, and only when, they appear in all 81 capitals, as shown here. 83 2. The 'tls-exporter' Channel Binding Type 85 Channel binding mechanisms are not useful until TLS implementations 86 expose the required data. To facilitate this, "tls-exporter" uses 87 exported keying material (EKM) which is already widely exposed by TLS 88 implementations. The EKM is obtained using the keying material 89 exporters for TLS as defined in [RFC5705] and [RFC8446] section 7.5 90 by supplying the following inputs: 92 Label: The ASCII string "EXPORTER-Channel-Binding" with no 93 terminating NUL. 95 Context value: Empty context value. 97 Length: 32 bytes. 99 3. Security Considerations 101 Channel bindings do not leak secret information about the channel and 102 are considered public. Implementations MUST NOT use the channel 103 binding to protect secret information. 105 The Security Considerations sections of [RFC5056], [RFC5705], and 106 [RFC8446] apply to this document. 108 3.1. Use with Legacy TLS 110 While it is possible to use this channel binding mechanism with TLS 111 versions below 1.3, extra precaution must be taken to ensure that the 112 chosen cipher suites always result in unique master secrets. For 113 more information see the Security Considerations section of 114 [RFC5705]. 116 When TLS renegotiation is enabled the "tls-exporter" channel binding 117 type is not defined and implementations MUST NOT support it. 119 In general, users wishing to take advantage of channel binding should 120 upgrade to TLS 1.3 or later. 122 4. IANA Considerations 124 4.1. Registration of Channel Binding Type 126 This document adds the following registration in the "Channel-Binding 127 Types" registry: 129 Subject: Registration of channel binding tls-exporter 131 Channel binding unique prefix: tls-exporter 133 Channel binding type: unique 135 Channel type: TLS [RFC8446] 137 Published specification: draft-ietf-kitten-tls-channel-bindings-for- 138 tls13-03 140 Channel binding is secret: no 142 Description: The EKM value obtained from the current TLS connection. 144 Intended usage: COMMON 145 Person and email address to contact for further information: Sam 146 Whited . 148 Owner/Change controller name and email address: IESG. 150 Expert reviewer name and contact information: IETF KITTEN or TLS WG 151 (kitten@ietf.org or tls@ietf.org, failing that, ietf@ietf.org). 153 Note: See the published specification for advice on the 154 applicability of this channel binding type. 156 4.2. Registration of Channel Binding TLS Exporter Label 158 This document adds the following registration in the "TLS Exporter 159 Labels" registry: 161 Value: EXPORTER-Channel-Binding 163 DTLS-OK: Y 165 Recommended: N 167 Reference: This document 169 5. References 171 5.1. Normative References 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, 175 DOI 10.17487/RFC2119, March 1997, 176 . 178 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 179 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 180 . 182 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 183 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 184 March 2010, . 186 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 187 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 188 May 2017, . 190 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 191 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 192 . 194 5.2. Informative References 196 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 197 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 198 . 200 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 201 Langley, A., and M. Ray, "Transport Layer Security (TLS) 202 Session Hash and Extended Master Secret Extension", 203 RFC 7627, DOI 10.17487/RFC7627, September 2015, 204 . 206 [TRIPLE-HANDSHAKE] 207 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 208 A., and P. Strub, "Password Storage", March 2014, 209 . 211 Author's Address 213 Sam Whited 214 Atlanta, GA 215 United States of America 217 Email: sam@samwhited.com 218 URI: https://blog.samwhited.com/