idnits 2.17.1 draft-ietf-tokbind-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 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.) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 16, 2019) is 1830 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Harper 3 Internet-Draft Google Inc. 4 Updates: RFC8472 (if approved) April 16, 2019 5 Intended status: Standards Track 6 Expires: October 18, 2019 8 Token Binding for Transport Layer Security (TLS) Version 1.3 Connections 9 draft-ietf-tokbind-tls13-03 11 Abstract 13 Negotiation of the Token Binding protocol is only defined for 14 Transport Layer Security (TLS) versions 1.2 and earlier. Token 15 Binding users may wish to use it with TLS 1.3; this document defines 16 a backwards compatible way to negotiate Token Binding on TLS 1.3 17 connections. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 18, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 Negotiating Token Binding using a TLS [RFC8446] extension as 54 described in [RFC8472] is fairly straightforward, but is restricted 55 to TLS 1.2 and earlier. Only one minor change is needed to use this 56 extension to negotiate Token Binding on connections using TLS 1.3 and 57 later. Instead of the server putting the "token_binding" extension 58 in the ServerHello like in TLS 1.2, in TLS 1.3 the server puts it in 59 EncryptedExtensions instead. 61 This document also non-normatively provides a clarification for the 62 definition of the TokenBinding.signature field from [RFC8471], since 63 TLS 1.3 defines an alternate (but API-compatible) exporter mechanism 64 to the one in [RFC5705] used in [RFC8471]. 66 1.1. Requirements Language 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 70 "OPTIONAL" in this document are to be interpreted as described in BCP 71 14 [RFC2119] [RFC8174] when, and only when, they appear in all 72 capitals, as shown here. 74 2. Token Binding TLS Extension 76 In TLS 1.3, the "token_binding" TLS extension may be present only in 77 ClientHello and EncryptedExtensions handshake messages. The format 78 of the "token_binding" TLS extension remains the same as defined in 79 [RFC8472]. 81 A client puts the "token_binding" TLS extension in its ClientHello to 82 indicate its support for the Token Binding protocol. The client 83 should follow the same rules for when to send this extension and the 84 contents of its data as in section 2 of [RFC8472]. Since the 85 "token_binding" extension remains unchanged from TLS 1.2 to TLS 1.3 86 in the ClientHello, a client sending the "token_binding" extension in 87 a TLS 1.3 ClientHello is backwards compatible with a server that only 88 supports TLS 1.2. 90 A server puts the "token_binding" TLS extension in the 91 EncryptedExtensions message following its ServerHello to indicate 92 support for the Token Binding protocol and to select protocol version 93 and key parameters. The server includes the extension following the 94 same rules as section 3 of [RFC8472], with the following changes: 96 o The "token_binding" TLS extension is in EncryptedExtensions 97 instead of ServerHello. 99 o The server MUST NOT include both the "token_binding" extension and 100 the "early_data" extension on the same connection. 102 3. Interaction with 0-RTT Data 104 [RFC8446] requires that extensions define their interaction with 105 0-RTT. The "token_binding" extension MUST NOT be used with 0-RTT 106 unless otherwise specified in another draft. A client MAY include 107 both "early_data" and "token_binding" extensions in its ClientHello - 108 this indicates that the client is willing to resume a connection and 109 send early data (without Token Binding), or negotiate Token Binding 110 on the connection and have early data rejected. 112 4. Clarification of TokenBinding.signature 114 This non-normative section provides a clarification on the definition 115 of the TokenBinding.signature field when used on a TLS 1.3 116 connection. 118 The Token Binding protocol [RFC8471] defines the 119 TokenBinding.signature field in terms of an exported keying material 120 (EKM) value as defined in [RFC5705]. TLS 1.3 [RFC8446] provides an 121 equivalent interface in section 7.5. For clarity, using the 122 terminology from [RFC8446], the EKM used in section 3.3 of [RFC8471] 123 in TLS 1.3 is the exporter value (section 7.5 of [RFC8446]) computed 124 with the following parameters: 126 o Secret: exporter_master_secret. 128 o label: The ASCII string "EXPORTER-Token-Binding" with no 129 terminating NUL. 131 o context_value: No context value is supplied. 133 o key_length: 32 bytes. 135 These are the same input values as specified in section 3.3 of 136 [RFC8471]. 138 5. Security Considerations 140 The consideration regarding downgrade attacks in [RFC8472] still 141 apply here: The parameters negotiated in the "token_binding" 142 extension are protected by the TLS handshake. An active network 143 attacker cannot modify or remove the "token_binding" extension 144 without also breaking the TLS connection. 146 This extension cannot be used with 0-RTT data, so the concerns in 147 [RFC8446] about replay do not apply here. 149 6. References 151 6.1. Normative References 153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 154 Requirement Levels", BCP 14, RFC 2119, 155 DOI 10.17487/RFC2119, March 1997, 156 . 158 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 159 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 160 May 2017, . 162 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 163 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 164 . 166 [RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport 167 Layer Security (TLS) Extension for Token Binding Protocol 168 Negotiation", RFC 8472, DOI 10.17487/RFC8472, October 169 2018, . 171 6.2. Informative References 173 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 174 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 175 March 2010, . 177 [RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, 178 "The Token Binding Protocol Version 1.0", RFC 8471, 179 DOI 10.17487/RFC8471, October 2018, 180 . 182 Author's Address 184 Nick Harper 185 Google Inc. 187 Email: nharper@google.com