idnits 2.17.1 draft-barnes-dane-uks-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** 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 204: '... that the server MUST assert some inte...' RFC 2119 keyword, line 214: '... TLS clients MUST verify that the se...' RFC 2119 keyword, line 217: '...ANE, TLS clients MUST verify that the ...' RFC 2119 keyword, line 222: '... selector=0) MUST contain the name...' RFC 2119 keyword, line 225: '...=0, match=0), clients MUST verify that...' (8 more instances...) -- The draft header indicates that this document updates RFC7671, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7250, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6698, 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 == Line 141 has weird spacing: '...ple.com victi...' -- The document date (October 9, 2016) is 2754 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-16 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) == Outdated reference: A later version (-07) exists of draft-ietf-tls-dnssec-chain-extension-01 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft M. Thomson 4 Updates: 6698, 7250, 7671 (if approved) E. Rescorla 5 Intended status: Informational Mozilla 6 Expires: April 12, 2017 October 9, 2016 8 Unknown Key-Share Attacks on DNS-based Authentications of Named Entities 9 (DANE) 10 draft-barnes-dane-uks-00 12 Abstract 14 Unknown key-share attacks are a class of attacks that allow an 15 attacker to deceive one peer of a secure communication as to the 16 identity of the remote peer. When used with traditional, PKI-based 17 authentication, TLS-based applications are generally safe from 18 unknown key-share attacks. DNS-based Authentication of Named 19 Entities (DANE), however, proposes that applications perform a 20 different set of checks as part of authenticating a TLS connection. 21 As a result, DANE as currently specified is likely to lead to unknown 22 key-share attacks when clients support DANE for authentication. We 23 describe these risks and some simple mitigations. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 12, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Attack Synopsis . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Attack Example . . . . . . . . . . . . . . . . . . . . . 3 62 3. Mitigations . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 6.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 TLS is very widely used to secure application protocols, and in 74 particular to authenticate the use of domain names for TLS servers. 75 Traditionally, TLS has authenticated a server's use of a domain name 76 by having the server present a certificate containing that name, then 77 having the client verify that the certificate attests to the name of 78 the server to which it was trying to connect (in addition to 79 verifying that the certificate is issued by a trusted authority) 80 [RFC5280] [RFC6125]. 82 DNS-based Authentication of Named Entities (DANE) makes modifications 83 to this process in order to accommodate the use of DNSSEC-signed 84 assertions acquired outside of TLS instead of certificates provided 85 in TLS [RFC6698]. This change, together with some recommended 86 changes to TLS usage and operational practices, make it possible for 87 an attacker to mount unknown key-share attacks against a TLS client 88 that supports DANE. 90 In this document, we describe how unknown key-share attacks arise 91 when a client supports DANE in the manner recommended by the DANE 92 specifications, and we propose some changes to DANE that remove these 93 risks. 95 2. Attack Synopsis 97 In an unknown key-share attack [UKS], a malicious participant in a 98 protocol claims to control a key that is in reality controlled by 99 some other actor. The victim client will believe that he is talking 100 to the attacker, when in reality he is talking to the victim server. 102 While this attack may sound less severe than attacks that let the 103 attacker claim an identity that is not his own, it can be used to 104 subvert identity-based access controls in the same way as an 105 impersonation attack. For example, a malicious web site could use an 106 unknown key-share attack to make a cross-origin request appear to be 107 same-origin, circumventing security checks on cross-origin requests 108 [W3C.CR-cors-20130129]. 110 TLS with PKI-based authentication is not vulnerable to unknown key- 111 share attacks because the server explicitly states its intended 112 identity in its certificate and the client verifies that the server's 113 asserted identity matches the client's intent. 115 When the client acquires DANE information out of band with respect to 116 TLS, it risks exposing itself to unknown key-share attacks if it 117 takes some additional steps recommended by the DANE specifications 118 [RFC7671] [RFC7250]. 120 o If the client does not verify the identity in the server's 121 certificate (as recommended in Section 5.1 of [RFC7671]), then an 122 attacker can induce the client to accept an unintended identity 123 for the server. 125 o If the client allows the use of raw public keys in TLS [RFC7250], 126 then it will not receive any indication of the server's identity 127 in the TLS channel, and is thus unable to check that the server's 128 identity is as intended. 130 2.1. Attack Example 132 In the natural version of this attack, the attacker convinces a 133 client that it has a TLS connection to attack.example.com (operated 134 by the attacker) when in reality, it has a TLS connection to 135 victim.example.org (operated by some innocent third party). 136 victim.example.org need not even be using DANE; it may have a 137 ordinary Web PKI certificate. In order to mount this attack, the 138 attacker provisions a TLSA record for attack.example.com authorizing 139 victim.example.com's public key. 141 Client attack.example.com victim.example.org 142 pubkey=P 143 |-_443._tcp.attack.example.com TLSA?-->| | 144 |<------TLSA usage=3 key=P-------------| | 145 | | 146 |<===============TLS==================>|<======TLS======>| 148 When the client connects to attack.example.com, the attacker forwards 149 the TLS messages to victim.example.org, which responds with its 150 ordinary certificate. With a non-DANE TLS connection, this would be 151 detected by the [RFC2818] or [RFC6125] certificate checks, but 152 [RFC7671] specifically instructs the client not to look at the name 153 in the certificate when DANE is in use. Instead, because since the 154 public key matches the TLSA record for attack.example.com, the client 155 accepts the connection as coming from attack.example.com - even 156 though it's actually to victim.example.org. 158 Depending on the application being run over TLS, this attack can lead 159 to different application-layer vulnerabilities. For example, if the 160 client uses the same TLS client authentication with both servers, the 161 attacker can convince the victim client to dereference a link 162 authorizing some action on the victim server, for instance 163 transfering money from the victim client to the attacker. 165 With a little more sophistication, the attacker can use this type of 166 attack to violate firewall restrictions. Consider the case where the 167 victim client and the victim server are behind the same firewall but 168 the victim server is unreachable to the attacker. The attacker can 169 exploit the client to recover content from the victim server by 170 combining this UKS attack with a DNS rebinding attack. 172 Client attack.example.com victim.example.org 173 IP=192.0.2.2 IP=198.51.100.1 IP=192.0.2.1 174 pubkey=P 175 |-_443._tcp.attack.example.com TLSA?-->| | 176 |<------TLSA usage=3 key=P------------ | | 177 | | | 178 |------ attack.example.com A? -------->| | 179 |<------------- 192.0.2.1 -------------| | 180 |<============================TLS========================>| 182 As before, the client connects to victim.example.org, thinking it is 183 attack.example.com, with the result that any data retrieved is same 184 origin to attack.example.com and therefore is accessible to script 185 from the attacker. This attack was already possible with HTTP 186 resources, but the UKS described here extends it to HTTPS resources. 188 There are several subtleties to note about this attack. First, it 189 requires the attacker to provide the client with two IP addresses in 190 sequence; first its true IP address (so it can retrieve the 191 attacker's page), not shown, and then the victim server's IP address 192 so that the client can contact the victim. This is known as DNS 193 rebinding. Second, the attacker must somehow retrieve the victim 194 server's public key (because it cannot contact the server directly). 195 One possible way to do this is through the Certificate Transparency 196 [RFC6962] logs. 198 3. Mitigations 200 At a high level, the mitigation to these attacks is to ensure that 201 when two peers negotiate a secure connection, they agree not just on 202 what public key the server is using, but also what name. 204 For TLS, this means that the server MUST assert some intended 205 identity (or identities) by including that identity under a signature 206 with its private key. In practice, there are two ways that this can 207 happen. Either the DANE record can contain a self-signed EE 208 certificate containing the identity, or the server can present a 209 certificate in the handshake that contains the name, where it is 210 transitively authenticated via the Finished MAC (and the 211 CertificateVerify in TLS 1.3 [I-D.ietf-tls-tls13]). 213 In order to avoid vulnerability to unknown key-share attacks, then, 214 TLS clients MUST verify that the server's name appears in one of 215 these two places: 217 o Even when using DANE, TLS clients MUST verify that the certificate 218 presented by the server represents the name they expect to connect 219 to [RFC6125]. 221 o End entity certificates asserted through DANE (usage=3, 222 selector=0) MUST contain the name being authenticated. 224 o When using a full EE certificate provided directly in a TLSA 225 record (usage=3, selector=0, match=0), clients MUST verify that 226 the certificate represents the name they expect to connect to. If 227 so, the client MAY accept the use of raw public keys in the 228 resulting TLS connection. When raw public keys are used in TLS, 229 the client MUST verify that the EE certificate presented in the 230 TLSA record is validly self-signed. 232 * It is only strictly necessary for the client to verify that the 233 EE certificate is correctly self-signed when the certificate is 234 asserted through DANE and raw public keys are used in the TLS 235 handshake. When the certificate is presented in the handshake, 236 the name is authenticated by the Finished MAC or 237 CertificateVerify signature (as noted above), so the client 238 only needs to check that the name is correct. 240 o When using a public key asserted through DANE (usage=3, 241 selector=1) the server MUST NOT accept the use of raw public keys. 243 o In general, TLS clients MUST NOT use raw public keys in TLS unless 244 the client is identifying the server by its public key directly, 245 as opposed to a name. 247 (Note that TLSA usages 0 and 1 are inherently not vulnerable to 248 unknown key-share attacks, since they are added checks on top of the 249 normal PKI-based authentication.) 251 The following table summarizes the above requirements for when raw 252 public keys may be used and where the server's name must appear. 253 "MAY*" indicates that the client MAY use raw public keys, but needs 254 to perform some additional checks. 256 +-------+----------+-----------+----------+---------------------+ 257 | Usage | Selector | Match | Raw key? | Name must appear... | 258 +-------+----------+-----------+----------+---------------------+ 259 | CA(2) | * | * | n/a | In TLS EE | 260 | | | | | | 261 | EE(3) | Full(0) | Exact(0) | MAY* | In TLSA or TLS EE | 262 | | | | | | 263 | EE(3) | Full(0) | Hash(1/2) | MUST NOT | In TLS EE | 264 | | | | | | 265 | EE(3) | SPKI(1) | * | MUST NOT | In TLS EE | 266 +-------+----------+-----------+----------+---------------------+ 268 The risk of unknown key-share attacks can also be removed by carrying 269 DANE records in the TLS handshake, as suggested in 270 [I-D.ietf-tls-dnssec-chain-extension]. In this case, the client MUST 271 verify that the name for which DANE information is provided is the 272 name it intended to connect to. 274 The directionality of these mitigations is important (server asserts; 275 client verifies). One might think that the opposite order would also 276 work, i.e., for the client to send a desired identity (e.g., in 277 Server Name Indication [RFC6066] or the HTTP Host header field 278 [RFC7230]) and the server to verify it before accepting the 279 handshake. However, servers today display a wide variety of 280 behaviors when presented with unknown SNI values (as would happen 281 during an unknown key share attack). While some fail safely, some 282 reroute to a default hostname. Thus, it is not possible for the 283 client to ensure that the server would fail safe. 285 In the longer term, DANE's susceptibility to unknown key-share 286 attacks could also be mitigated with a re-design of TLSA records 287 themselves. If DANE records included (1) the names being vouched 288 for, and (2) a signature by the key pair being asserted over the 289 contents of the record, then DANE would effectively always be in the 290 "EE / Full / Exact" case above, since the DANE record would have the 291 same semantics as a self-signed certificate (at least in the ways 292 that matter here). Then it would be safe to use all DANE cases with 293 raw public keys, since no name checks would need to be done at the 294 TLS layer. 296 4. IANA Considerations 298 This document makes no request of IANA. 300 5. Security Considerations 302 This section intentionally left blank. 304 6. References 306 6.1. Normative References 308 [I-D.ietf-tls-tls13] 309 Rescorla, E., "The Transport Layer Security (TLS) Protocol 310 Version 1.3", draft-ietf-tls-tls13-16 (work in progress), 311 September 2016. 313 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 314 DOI 10.17487/RFC2818, May 2000, 315 . 317 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 318 Housley, R., and W. Polk, "Internet X.509 Public Key 319 Infrastructure Certificate and Certificate Revocation List 320 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 321 . 323 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 324 Verification of Domain-Based Application Service Identity 325 within Internet Public Key Infrastructure Using X.509 326 (PKIX) Certificates in the Context of Transport Layer 327 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 328 2011, . 330 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 331 of Named Entities (DANE) Transport Layer Security (TLS) 332 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 333 2012, . 335 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 336 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 337 . 339 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 340 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 341 Transport Layer Security (TLS) and Datagram Transport 342 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 343 June 2014, . 345 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 346 Authentication of Named Entities (DANE) Protocol: Updates 347 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 348 October 2015, . 350 [UKS] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share 351 Attacks on the Station-to-Station (STS) Protocol", Lecture 352 Notes in Computer Science 1560, Springer, pp. 154-170 , 353 1999. 355 6.2. Informative References 357 [I-D.ietf-tls-dnssec-chain-extension] 358 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 359 Record and DNSSEC Authentication Chain Extension for TLS", 360 draft-ietf-tls-dnssec-chain-extension-01 (work in 361 progress), July 2016. 363 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 364 Extensions: Extension Definitions", RFC 6066, 365 DOI 10.17487/RFC6066, January 2011, 366 . 368 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 369 Protocol (HTTP/1.1): Message Syntax and Routing", 370 RFC 7230, DOI 10.17487/RFC7230, June 2014, 371 . 373 [W3C.CR-cors-20130129] 374 Kesteren, A., "Cross-Origin Resource Sharing", World Wide 375 Web Consortium CR CR-cors-20130129, January 2013, 376 . 378 Appendix A. Acknowledgements 380 The considerations in this document are largely based on Martin 381 Thomson and Eric Rescorla's work with Karthik Bhargavan on the 382 analogous problem in DTLS-SRTP. 384 Authors' Addresses 386 Richard Barnes 387 Mozilla 389 Email: rlb@ipv.sx 391 Martin Thomson 392 Mozilla 394 Email: martin.thomson@gmail.com 396 Eric Rescorla 397 Mozilla 399 Email: ekr@rftm.com