Appendix on RPK misbinding attacks #1366
Conversation
| @@ -6125,6 +6137,11 @@ analysis has been done. Implementations can ensure safety from | |||
| cross-protocol related output by not reusing PSKs between TLS 1.3 and | |||
| TLS 1.2. | |||
|
|
|||
| ## Misbinding when using RPKs | |||
There was a problem hiding this comment.
| ## Misbinding when using RPKs | |
| ## Misbinding Using Raw Public Keys |
| @@ -6125,6 +6137,11 @@ analysis has been done. Implementations can ensure safety from | |||
| cross-protocol related output by not reusing PSKs between TLS 1.3 and | |||
| TLS 1.2. | |||
|
|
|||
| ## Misbinding when using RPKs | |||
|
|
|||
| When TLS 1.3 is used with raw public keys {{RFC7250}} for peer authentication, it may be vulnerable to misbinding attacks {{MM24}}. To mitigate this risk, if only the TLS server is authenticated using the RawPublicKey certificate type, the server SHOULD enforce strict validation of the "server_name" extension received in the ClientHello to confirm that the client intended to establish a connection with the server. Alternatively, or when both the client and server authenticate using the RawPublicKey certificate type, the endpoints SHOULD perform identity verification using either the "external_id_hash" TLS extension {{RFC8844}}, or at the application layer after the TLS connection is established. | |||
There was a problem hiding this comment.
Wrap this paragraph for consistency with the rest of the document.
Good point. Perhaps: "the server SHOULD check that the name received in the "server_name" extension of the ClientHello is something that it recognizes and is willing to respond to, ensuring that the client intended to establish a connection with the server receiving the ClientHello." |
|
Client has no way to know if SNI is validated by the server, so the SNI check is not reliable. Only external_id_hash would be a reliable check. Also, the suggestion to use application verification needs to be stronger; HTTP has its "Host:" header (which should probably be called out in the text), however the Host header also suffers the same weakness as TLS SNI: the client has no way to determine if the server is validating the Host header. |
| @@ -6125,6 +6137,11 @@ analysis has been done. Implementations can ensure safety from | |||
| cross-protocol related output by not reusing PSKs between TLS 1.3 and | |||
| TLS 1.2. | |||
|
|
|||
| ## Misbinding when using RPKs | |||
|
|
|||
| When TLS 1.3 is used with raw public keys {{RFC7250}} for peer authentication, it may be vulnerable to misbinding attacks {{MM24}}. To mitigate this risk, if only the TLS server is authenticated using the RawPublicKey certificate type, the server SHOULD enforce strict validation of the "server_name" extension received in the ClientHello to confirm that the client intended to establish a connection with the server. Alternatively, or when both the client and server authenticate using the RawPublicKey certificate type, the endpoints SHOULD perform identity verification using either the "external_id_hash" TLS extension {{RFC8844}}, or at the application layer after the TLS connection is established. | |||
There was a problem hiding this comment.
In many applications, only the server identity is verified, so we want to allow the client to validate the server's identity (without requiring mutual TLS). Suggested change below.
| When TLS 1.3 is used with raw public keys {{RFC7250}} for peer authentication, it may be vulnerable to misbinding attacks {{MM24}}. To mitigate this risk, if only the TLS server is authenticated using the RawPublicKey certificate type, the server SHOULD enforce strict validation of the "server_name" extension received in the ClientHello to confirm that the client intended to establish a connection with the server. Alternatively, or when both the client and server authenticate using the RawPublicKey certificate type, the endpoints SHOULD perform identity verification using either the "external_id_hash" TLS extension {{RFC8844}}, or at the application layer after the TLS connection is established. | |
| When TLS 1.3 is used with raw public keys {{RFC7250}} for peer authentication, it may be vulnerable to misbinding attacks {{MM24}}. To mitigate this risk, if only the TLS server is authenticated using the RawPublicKey certificate type, the server SHOULD enforce strict validation of the "server_name" extension received in the ClientHello to confirm that the client intended to establish a connection with the server. Alternatively, the endpoints SHOULD perform identity verification of the peer using the "external_id_hash" TLS extension {{RFC8844}}, or at the application layer after the TLS connection is established. |
No description provided.