From 0db38a0d74b3621362ddd6401f350935a7fcf0ef Mon Sep 17 00:00:00 2001 From: Dan Wing Date: Thu, 12 Dec 2024 12:56:35 -0800 Subject: [PATCH 1/6] add text on mitigating TLS misbinding attack --- draft-thomson-https-local-domains.md | 57 +++++++++++++++++++++++++++- 1 file changed, 55 insertions(+), 2 deletions(-) diff --git a/draft-thomson-https-local-domains.md b/draft-thomson-https-local-domains.md index 3f8c29f..84c5e2e 100644 --- a/draft-thomson-https-local-domains.md +++ b/draft-thomson-https-local-domains.md @@ -55,6 +55,34 @@ informative: name: Chelsea Novak target: https://blog.mozilla.org/en/products/firefox/introducing-firefox-multi-account-containers/ + MM24: + title: "Misbinding Raw Public Keys to Identities in TLS" + date: 2024 + target: https://arxiv.org/pdf/2411.09770 + author: + - + ins: M. Moustafa + - + ins: M. Sethi + - + ins: T. Aura + + SIGMA: + title: "SIGMA: The ‘SIGn-and-MAc’ Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols" + date: 2003 + author: + name: Hugo Krawczyk + target: https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24 + + tls-misbinding: + title: "TLS 1.3, Raw Public Keys, and Misbinding Attacks" + date: March 2024 + author: + name: John Mattsson + target: https://mailarchive.ietf.org/arch/msg/tls/NaXngZTt_yTXhWGUNj85TBBdjQI/ + seriesinfo: + "TLS WG": "mailing list thread" + --- abstract This document explores a method for providing secure HTTPS access @@ -544,7 +572,7 @@ This section defines the domain names and IP addresses considered names and other IP addresses SHOULD NOT be used with this specification. -## Local Domain Names +## Local Domain Names {#local-domain-names} The following domain name suffixes are considered "local": @@ -552,6 +580,7 @@ The following domain name suffixes are considered "local": * ".home-arpa" (from {{?Homenet=RFC8375}}) * ".internal" (from {{?I-D.davies-internal-tld}}) * both ".localhost" and "localhost" (Section 6.3 of {{?RFC6761}}) +* domain name of the DNS search domain (for further discussion) ## Local IP Addresses @@ -566,7 +595,7 @@ connection is made to that address, those are also considered # Operational Considerations -## Incremental Deployment +## Incremental Deployment {#incremental} Where a server's hostname can be configured, a motivated network administrator can configure server hostnames to comply with this @@ -609,6 +638,30 @@ New registry for hash type, 0=SHA256. Extensions via IETF Action. This should work for DTLS, as well? +## Misbinding TLS Raw Public Keys + +> This section is for discussion: is mitigation of TLS misbinding +attack necessary. It appears to not have achieved consensus during +the discussion on the TLS mailing list ({{tls-misbinding}}), but the method proposed in +this draft has not yet been discussed. Note also requiring the +mitigation in this section prevents incremental deployment +({{incremental}}) as it requires servers support the external_id_hash +extension + +To prevent TLS misbinding attack {{MM24}} the server needs to include +its identity to the client in the TLS handshake {{SIGMA}}. The server +can have several identities in different domains, see {{local-domain-names}}. + +To verify server identity, the client MUST include both the TLS Server +Name Indication (SNI) and an empty external_id_hash {{!RFC8844}} in +its ClientHello. The server MUST include the hash of its identity +matching the SNI in the external_id_hash extension of its response (in +the EncryptedExtensions message if using TLS 1.3, as specified in +{{RFC8844}}). If server does not have an identity matching the SNI and +the ClientHello contains the external_id_hash extension, the server +returns an empty external_id_hash. Upon receipt, the client verifies +the external_id_hash matches the TLS SNI value sent earlier; if they +mismatch the TLS session is aborted. # Test Encoding {#test-encoding} From b2cbff00819e9f618630596038e1d5fe75279fb7 Mon Sep 17 00:00:00 2001 From: Dan Wing Date: Fri, 13 Dec 2024 08:11:13 -0800 Subject: [PATCH 2/6] incremental deployment works fine, because old servers will have a certificate containing their hostname (even if self-signed, but that's not a new issue we created with this draft) --- draft-thomson-https-local-domains.md | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/draft-thomson-https-local-domains.md b/draft-thomson-https-local-domains.md index 84c5e2e..1aa9ce5 100644 --- a/draft-thomson-https-local-domains.md +++ b/draft-thomson-https-local-domains.md @@ -437,6 +437,12 @@ the client authenticates the TLS connection. If they do not match, the client behavior falls back to the client's normal handling of the presented TLS raw public key or certificate (which may well be valid). +If the server does not support the TLS external_id_hash extension +({{misbinding}}) and does return a SubjectAltName in the certificate, +the client MUST validate the SubjectAltName matches the expected +hostname, as normal. If, however, the server does not support +the TLS external_id_hash extension and returns a raw public key, +the client MUST abort the TLS connection (see also {{misbinding}}). # Unique Host Names {#unique} @@ -638,22 +644,21 @@ New registry for hash type, 0=SHA256. Extensions via IETF Action. This should work for DTLS, as well? -## Misbinding TLS Raw Public Keys +## Misbinding TLS Raw Public Keys {#misbinding} > This section is for discussion: is mitigation of TLS misbinding attack necessary. It appears to not have achieved consensus during the discussion on the TLS mailing list ({{tls-misbinding}}), but the method proposed in -this draft has not yet been discussed. Note also requiring the -mitigation in this section prevents incremental deployment -({{incremental}}) as it requires servers support the external_id_hash -extension +this draft has not yet been discussed. To prevent TLS misbinding attack {{MM24}} the server needs to include -its identity to the client in the TLS handshake {{SIGMA}}. The server -can have several identities in different domains, see {{local-domain-names}}. +its identity to the client in the TLS handshake {{SIGMA}}. A server +using raw public keys does not have its name encoded into that key. +The server is expected to have several identities in different +domains, see {{local-domain-names}}. To verify server identity, the client MUST include both the TLS Server -Name Indication (SNI) and an empty external_id_hash {{!RFC8844}} in +Name Indication (SNI) and an empty external_id_hash {{!RFC8844}} extension in its ClientHello. The server MUST include the hash of its identity matching the SNI in the external_id_hash extension of its response (in the EncryptedExtensions message if using TLS 1.3, as specified in From 0a8d93235254005839054d739907dd0332e2ac56 Mon Sep 17 00:00:00 2001 From: Dan Wing Date: Fri, 13 Dec 2024 16:12:19 -0800 Subject: [PATCH 3/6] the name is the (public) key hash, so rebinding attack can't happen to us --- draft-thomson-https-local-domains.md | 88 +++++++++------------------- 1 file changed, 28 insertions(+), 60 deletions(-) diff --git a/draft-thomson-https-local-domains.md b/draft-thomson-https-local-domains.md index 1aa9ce5..3e9ddc6 100644 --- a/draft-thomson-https-local-domains.md +++ b/draft-thomson-https-local-domains.md @@ -56,32 +56,16 @@ informative: target: https://blog.mozilla.org/en/products/firefox/introducing-firefox-multi-account-containers/ MM24: - title: "Misbinding Raw Public Keys to Identities in TLS" - date: 2024 - target: https://arxiv.org/pdf/2411.09770 - author: - - - ins: M. Moustafa - - - ins: M. Sethi - - - ins: T. Aura - - SIGMA: - title: "SIGMA: The ‘SIGn-and-MAc’ Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols" - date: 2003 - author: - name: Hugo Krawczyk - target: https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24 - - tls-misbinding: - title: "TLS 1.3, Raw Public Keys, and Misbinding Attacks" - date: March 2024 - author: - name: John Mattsson - target: https://mailarchive.ietf.org/arch/msg/tls/NaXngZTt_yTXhWGUNj85TBBdjQI/ - seriesinfo: - "TLS WG": "mailing list thread" + title: "Misbinding Raw Public Keys to Identities in TLS" + date: 2024 + target: https://arxiv.org/pdf/2411.09770 + author: + - + ins: M. Moustafa + - + ins: M. Sethi + - + ins: T. Aura --- abstract @@ -430,19 +414,18 @@ When clients connect to such a local domain name or IP address registered hash identifier in the second label and if the rest of that label consists of an appropriate-length encoded hash. If those conditions apply, the client MAY send a TLS ClientHello with the Raw -Public Key extension {{?RFC7250}}. When the client receives the -server's raw public key or certificate, the client checks if the hash +Public Key extension {{?RFC7250}}. + +When the client receives the +server's raw public key or certificate, the client checks if the public key hash matches the public key received in the TLS ServerHello. If they match, the client authenticates the TLS connection. If they do not match, the client behavior falls back to the client's normal handling of the presented TLS raw public key or certificate (which may well be valid). -If the server does not support the TLS external_id_hash extension -({{misbinding}}) and does return a SubjectAltName in the certificate, -the client MUST validate the SubjectAltName matches the expected -hostname, as normal. If, however, the server does not support -the TLS external_id_hash extension and returns a raw public key, -the client MUST abort the TLS connection (see also {{misbinding}}). +If the server returns a certificate (rather than a raw public key), +the client validates the certificate as normal (e.g., validity date, +signed by a trusted Certification Authority, and so on). # Unique Host Names {#unique} @@ -578,7 +561,7 @@ This section defines the domain names and IP addresses considered names and other IP addresses SHOULD NOT be used with this specification. -## Local Domain Names {#local-domain-names} +## Local Domain Names The following domain name suffixes are considered "local": @@ -586,7 +569,6 @@ The following domain name suffixes are considered "local": * ".home-arpa" (from {{?Homenet=RFC8375}}) * ".internal" (from {{?I-D.davies-internal-tld}}) * both ".localhost" and "localhost" (Section 6.3 of {{?RFC6761}}) -* domain name of the DNS search domain (for further discussion) ## Local IP Addresses @@ -601,7 +583,7 @@ connection is made to that address, those are also considered # Operational Considerations -## Incremental Deployment {#incremental} +## Incremental Deployment Where a server's hostname can be configured, a motivated network administrator can configure server hostnames to comply with this @@ -630,6 +612,15 @@ for local servers. In this case, the advantages of making HTTPS available would seem to far outweigh the risk of using a key over long periods. +## Misbinding TLS Raw Public Keys {#misbinding} + +When using Raw Public Keys a misbinding attack is possible when the +server name is not cryptographically bound to the TLS handshake +({{MM24}}). The mechanism described in this draft avoids such a +misbinding because the public key is included in the handshake, which +the client verifies matches the hash of the public key contained in +the hostname. This obviates the need for mitigations described in +{{?RFC8844}}. # IANA Considerations {#iana} @@ -644,29 +635,6 @@ New registry for hash type, 0=SHA256. Extensions via IETF Action. This should work for DTLS, as well? -## Misbinding TLS Raw Public Keys {#misbinding} - -> This section is for discussion: is mitigation of TLS misbinding -attack necessary. It appears to not have achieved consensus during -the discussion on the TLS mailing list ({{tls-misbinding}}), but the method proposed in -this draft has not yet been discussed. - -To prevent TLS misbinding attack {{MM24}} the server needs to include -its identity to the client in the TLS handshake {{SIGMA}}. A server -using raw public keys does not have its name encoded into that key. -The server is expected to have several identities in different -domains, see {{local-domain-names}}. - -To verify server identity, the client MUST include both the TLS Server -Name Indication (SNI) and an empty external_id_hash {{!RFC8844}} extension in -its ClientHello. The server MUST include the hash of its identity -matching the SNI in the external_id_hash extension of its response (in -the EncryptedExtensions message if using TLS 1.3, as specified in -{{RFC8844}}). If server does not have an identity matching the SNI and -the ClientHello contains the external_id_hash extension, the server -returns an empty external_id_hash. Upon receipt, the client verifies -the external_id_hash matches the TLS SNI value sent earlier; if they -mismatch the TLS session is aborted. # Test Encoding {#test-encoding} From 7e0fa7a1a69808228f1193b047c84afc5f36848d Mon Sep 17 00:00:00 2001 From: Dan Wing Date: Fri, 13 Dec 2024 16:29:04 -0800 Subject: [PATCH 4/6] Update draft-thomson-https-local-domains.md Co-authored-by: Sridharan Rajagopalan --- draft-thomson-https-local-domains.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-thomson-https-local-domains.md b/draft-thomson-https-local-domains.md index 3e9ddc6..714ccfb 100644 --- a/draft-thomson-https-local-domains.md +++ b/draft-thomson-https-local-domains.md @@ -614,7 +614,7 @@ risk of using a key over long periods. ## Misbinding TLS Raw Public Keys {#misbinding} -When using Raw Public Keys a misbinding attack is possible when the +When using Raw Public Keys, a misbinding attack is possible when the server name is not cryptographically bound to the TLS handshake ({{MM24}}). The mechanism described in this draft avoids such a misbinding because the public key is included in the handshake, which From 437f0c9138adf7ded4ec258e5e9fc6032f1e6a29 Mon Sep 17 00:00:00 2001 From: Dan Wing Date: Fri, 13 Dec 2024 16:35:39 -0800 Subject: [PATCH 5/6] slight rewording --- draft-thomson-https-local-domains.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/draft-thomson-https-local-domains.md b/draft-thomson-https-local-domains.md index 3e9ddc6..7f3fbd3 100644 --- a/draft-thomson-https-local-domains.md +++ b/draft-thomson-https-local-domains.md @@ -614,13 +614,13 @@ risk of using a key over long periods. ## Misbinding TLS Raw Public Keys {#misbinding} -When using Raw Public Keys a misbinding attack is possible when the -server name is not cryptographically bound to the TLS handshake -({{MM24}}). The mechanism described in this draft avoids such a -misbinding because the public key is included in the handshake, which -the client verifies matches the hash of the public key contained in -the hostname. This obviates the need for mitigations described in -{{?RFC8844}}. +When using Raw Public Keys a misbinding attack (unknown key-share +attack) is possible when the server name is not cryptographically +bound to the TLS handshake ({{MM24}}). The mechanism described in +this draft avoids such an attack because the public key is included in +the handshake, which the client verifies matches the public key hash +contained in the hostname. This obviates the need for mitigations +described in {{?RFC8844}}. # IANA Considerations {#iana} From 56661624f2382c310a13e09eb0815f12d5e0958c Mon Sep 17 00:00:00 2001 From: Dan Wing Date: Fri, 13 Dec 2024 16:58:49 -0800 Subject: [PATCH 6/6] more wording tweak. cite PKIX and RFC9525 --- draft-thomson-https-local-domains.md | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/draft-thomson-https-local-domains.md b/draft-thomson-https-local-domains.md index 70f8541..535e409 100644 --- a/draft-thomson-https-local-domains.md +++ b/draft-thomson-https-local-domains.md @@ -416,16 +416,14 @@ label consists of an appropriate-length encoded hash. If those conditions apply, the client MAY send a TLS ClientHello with the Raw Public Key extension {{?RFC7250}}. -When the client receives the -server's raw public key or certificate, the client checks if the public key hash -matches the public key received in the TLS ServerHello. If they match, -the client authenticates the TLS connection. If they do not match, the -client behavior falls back to the client's normal handling of the -presented TLS raw public key or certificate (which may well be valid). - -If the server returns a certificate (rather than a raw public key), -the client validates the certificate as normal (e.g., validity date, -signed by a trusted Certification Authority, and so on). +When the client receives the server's raw public key or certificate, +the client checks if the public key hash matches the public key +received in the TLS ServerHello. If they match, the client +authenticates the TLS connection. If they do not match and the +response contains a raw public key, the TLS connection is aborted. If +they do not match and the response contains a certificate, the client +validates or rejects the certificate using its normal procedures +({{?RFC9525}}, {{?PKIX=RFC5280}}). # Unique Host Names {#unique} @@ -614,7 +612,7 @@ risk of using a key over long periods. ## Misbinding TLS Raw Public Keys {#misbinding} -When using Raw Public Keys, a misbinding attack (unknown key-share +When using Raw Public Keys, a misbinding attack (also called unknown key-share attack) is possible when the server name is not cryptographically bound to the TLS handshake ({{MM24}}). The mechanism described in this draft avoids such an attack because the public key is included in