idnits 2.17.1 draft-huque-tls-dane-clientid-02.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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 112: '...is specification SHOULD send an extens...' RFC 2119 keyword, line 121: '... field of the extension MUST contain a...' RFC 2119 keyword, line 143: '... ClientNameList MUST NOT contain more...' RFC 2119 keyword, line 146: '...is specification MAY send back an empt...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 October 2020) is 1289 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'DANECLIENT' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECH' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Huque 3 Internet-Draft Salesforce 4 Intended status: Standards Track V. Dukhovni 5 Expires: 11 April 2021 Two Sigma 6 8 October 2020 8 TLS Extension for DANE Client Identity 9 draft-huque-tls-dane-clientid-02 11 Abstract 13 This document specifies a TLS and DTLS extension to convey a DNS- 14 Based Authentication of Named Entities (DANE) Client Identity to a 15 TLS or DTLS server. This is useful for applications that perform TLS 16 client authentication via DANE TLSA records. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 11 April 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. DANE Client Identity Extension . . . . . . . . . . . . . . . 3 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 59 1. Introduction 61 This document specifies a Transport Layer Security (TLS) extension 62 [RFC6066] to convey a DANE [RFC6698] Client Identity to the TLS 63 server. This is useful for applications that perform TLS client 64 authentication via DANE TLSA records, as described in [DANECLIENT]. 65 The extension could be empty to indicate to the server that the 66 client has a DANE record and that the server can perform DANE 67 authentication of the client with the identity extracted from the 68 client certificate. Or the extension can contain the full client 69 identity, in the form of the DNS domain name that is expected to have 70 a DANE TLSA record published for it. 72 This extension supports both TLS [RFC5246] [RFC8446] and DTLS 73 [RFC6347], and the term TLS in this document is used generically to 74 describe both protocols. 76 2. Overview 78 When TLS clients use X.509 client certificates or raw public keys 79 that are authenticated via DANE TLSA records, it is useful for them 80 to convey their intent to be authenticated via DANE, or even to 81 convey their complete DANE identity to the server. The TLS extension 82 defined in this document is used to accomplish this. 84 In the case of X.509 client certificates, a TLS server can learn the 85 client's identity by examining subject alternative names included in 86 the certificate itself. However, without a mechanism such as the one 87 defined in this extension, the TLS server cannot know apriori that 88 the client has a published TLSA record, and thus may unnecessarily 89 issue DNS queries for DANE TLSA records in-band with the TLS 90 handshake even in cases where the client has no TLSA record 91 associated with it. When multiple identities are present in the 92 certificate, a client can use this extension to specify exactly which 93 one the server should use. An additional situation in which this 94 extension helps is where some TLS servers may need to selectively 95 prompt for client certificate credentials only for clients that are 96 equipped to provide certificates. 98 When TLS raw public keys [RFC7250] are being used to authenticate the 99 client, the client uses this extension to explicitly indicate to the 100 server what its domain name identity is (since there is no X.509 101 certificate from which the identity can be extracted). 103 Detailed protocol behavior of TLS clients and servers is described in 104 [DANECLIENT]. 106 3. DANE Client Identity Extension 108 The DANE Client Identity Extension type, "dane_clientid", will have a 109 value assigned and registered in the IANA TLS Extensions registry. 110 Its format is similar to the TLS Server Name Indication extension. 112 A TLS client implementing this specification SHOULD send an extension 113 of type "dane_clientid" in the ClientHello handshake message to TLS 114 servers it intends to perform DANE client authentication with. 116 If the client only needs to indicate that it has a DANE record and 117 that the client's domain name identity can be obtained from its 118 certificate, then the extension sent can be empty. 120 If the client additionally needs to send its domain name identity, 121 then the "extension_data" field of the extension MUST contain a 122 "ClientNameList" data structure defined in the following format: 124 struct { 125 NameType name_type; 126 select (name_type) { 127 case host_name: HostName; 128 } name; 129 } ClientName; 131 enum { 132 host_name(0), (255) 133 } NameType; 135 opaque HostName<1..2^16-1>; 137 struct { 138 ClientName client_name_list<1..2^16-1> 139 } ClientNameList; 141 The opaque HostName field contains the domain name of the client in 142 textual presentation format, as described in RFC 1035 [RFC1035]. The 143 ClientNameList MUST NOT contain more than one name of the same 144 name_type. Currently only one "host_name" type is defined. 146 A TLS server implementing this specification MAY send back an empty 147 extension of type "dane_clientid" in its SeverHello handshake message 148 to indicate that it understands the extension and intends to perform 149 DANE client authentication. (Is there a compelling reason to do 150 this?) 152 4. Security Considerations 154 This extension is sent in the first flight of the TLS client's 155 network data (Client Hello), which is in clear text. 157 To prevent unnecessary privacy leakage of the client's name in 158 cleartext, a TLS client implementing this specification should be 159 configured to only send this extension to TLS servers it intends to 160 perform client authentication with. 162 Ideally, this extension should be used with the proposed TLS 163 Encrypted Client Hello extension [ECH], which encrypts the entire 164 Client Hello message. This will prevent leakage of the hostname, if 165 included in the extension, in clear text. 167 5. IANA Considerations 169 This extension requires the registration of a new value in the TLS 170 ExtensionsType registry. 172 6. Normative References 174 [DANECLIENT] 175 Huque, S. and V. Dukhovni, "TLS Client Authentication via 176 DANE TLSA Records", . 179 [ECH] Rescorla, E., Oku, K., Sullivan, N., and C.A. Wood, "TLS 180 Encrypted Client Hello", 181 . 183 [RFC1035] Mockapetris, P., "Domain names - implementation and 184 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 185 November 1987, . 187 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 188 (TLS) Protocol Version 1.2", RFC 5246, 189 DOI 10.17487/RFC5246, August 2008, 190 . 192 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 193 Extensions: Extension Definitions", RFC 6066, 194 DOI 10.17487/RFC6066, January 2011, 195 . 197 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 198 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 199 January 2012, . 201 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 202 of Named Entities (DANE) Transport Layer Security (TLS) 203 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 204 2012, . 206 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 207 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 208 Transport Layer Security (TLS) and Datagram Transport 209 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 210 June 2014, . 212 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 213 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 214 . 216 Authors' Addresses 218 Shumon Huque 219 Salesforce 221 Email: shuque@gmail.com 223 Viktor Dukhovni 224 Two Sigma 226 Email: ietf-dane@dukhovni.org