[TLS] Re: TLS 1.3, Raw Public Keys, and Misbinding Attacks

[Mohit Sethi <[e-mail]>]

Hi Hannes, all,

Coming back to this. I'd disagree with the assertion that when using the 
raw public key mode, the public key is the identity. We don't open a 
connection to a key - we open a connection to a domain name or to an IP 
address .... unless of course we are a HIPster and use Host Identity 
Protocol (HIP) such that the key and the address is strongly intertwined.

John is right here, if we don't include the server identity (e.g.: 
domain name) in the handshake or verify it separately, then misbinding 
is possible. We modeled TLS RPK with Proverif and found that misbinding 
is possible: https://arxiv.org/pdf/2411.09770. The model detects 
misbinding in both cases: i) where the received public key is verified 
via DANE, and ii) where the received public key is verified from a list 
of pre-configured of keys.

In fact, the existence of misbinding of TLS RPK can easily tested in the 
real-world with OpenSSL using the following command (version 3.2.0 and up):

> openssl s_client -connect msguru.eu:25 -dane_tlsa_domain "msguru.eu" 
> -dane_tlsa_rrdata "3 1 1 
> F4D9CF3B4E251085A4F3193DAAF3A5141CD95C7109D33C971C3F8F7CEC48CD1B" 
> -starttls smtp -enable_server_rpk

The above command results in a successful TLS handshake as is evident 
from the output:

> Server-to-client raw public key negotiated
> Server raw public key
>   Public-Key: (2048 bit)
>   Modulus:
>       00:c8:eb:ec:64:97:5d:aa:b6:99:06:68:13:8d:76:
>       ff:31:06:77:fa:30:d0:a8:91:8e:90:fa:d5:77:7d:
>       ad:0c:a3:5d:20:23:ee:b9:c7:23:5e:e4:3f:60:cd:
>       6e:e6:2d:84:16:8e:03:ab:5b:a9:b3:ce:38:16:2d:
>       6b:82:8f:22:ab:2c:23:19:7d:30:57:95:10:80:fe:
>       d4:50:e5:c5:e3:c0:78:dc:86:31:87:aa:46:c8:95:
>       3f:4a:8c:eb:21:58:f3:3b:c4:c9:1d:a4:53:cc:0e:
>       79:ae:3c:92:d3:ac:9f:6f:34:5d:b6:78:92:29:27:
>       70:a7:14:4e:26:ed:76:aa:81:ea:27:79:37:68:3c:
>       20:4e:11:8a:30:c3:ff:93:c9:ee:24:a4:29:2a:44:
>       bf:40:c2:1e:bd:cb:f7:1d:c6:f2:81:16:14:73:a8:
>       88:09:10:bc:95:56:62:17:8c:db:55:ce:14:b0:70:
>       d0:69:54:84:20:5e:b7:35:74:91:8d:1c:c0:3d:95:
>       be:41:c0:6e:d4:34:6c:eb:25:7d:fd:c9:45:9c:e6:
>       e6:9e:07:dd:28:22:70:34:7d:80:8d:43:6f:26:88:
>       80:81:8c:02:95:dc:6f:3e:8f:ee:c1:df:95:a0:b8:
>       58:78:15:bf:47:67:c7:b4:07:22:3e:ca:04:5e:3f:
>       01:f7
>   Exponent: 65537 (0x10001)
> ---
> SSL handshake has read 1066 bytes and written 444 bytes
> Verification: OK
> DANE TLSA 3 1 1 ...09d33c971c3f8f7cec48cd1b matched the peer raw 
> public key
> ---
However, there is no server msguru.eu listening on port 25. Instead you 
are connected to Viktor's mail server at mx1.imrryr.org which supports 
server authentication with RPKs and has a DANE record published: 
https://www.nslookup.io/domains/_25._tcp.mx1.imrryr.org/dns-records/tlsa/. 
Thankfully, most ISPs block outbound port 25 and therefore Viktor's mail 
server is not suddenly going to see a massive spurt in traffic. The fact 
that someone can publish a different MX record as their own and that the 
SNI can be used to detect such situation was already pointed out by 
Viktor in his email: 
https://mailarchive.ietf.org/arch/msg/tls/ey_rNTC8Um1OMD5cxjkpZ1OyInQ/.

The lesson here is the same countermeasure for all misbinding attack - 
be explicit about the identities and check them. We have created a pull 
request for 8446bis adding a reference to misbinding attacks and 
countermeasures when using RPK. The goal was to keep the text to a minimum:

https://github.com/tlswg/tls13-spec/pull/1366

Feel free to modify the pull request and use! We welcome any further 
discussion.

PS: We have some other results we are working on and will be happy to 
present them together at one of the upcoming IETF meetings (likely 123 
in Madrid).

On 4/16/24 12:30, Tschofenig, Hannes wrote:
>
> Hi John,
>
> I missed this email exchange and I largely agree with what has been 
> said by others before.
>
> I disagree with your conclusion since the “identity” in the raw public 
> key case is the public key.
>
> With the self-signed certificate there would the danger that the 
> self-asserted identity in the certificate is actually used for anything.
>
> Ciao
>
> Hannes
>
> *From:*TLS <[e-mail]> *On Behalf Of *John Mattsson
> *Sent:* Thursday, March 28, 2024 4:22 PM
> *To:* [e-mail]
> *Subject:* [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks
>
> Hi,
>
> I looked into what RFC 8446(bis) says about Raw Public Keys. As 
> correctly stated in RFC 8446, TLS 1.3 with signatures and certificates 
> is an implementation of SIGMA-I:
>
> SIGMA does however require that the identities of the endpoints 
> (called A and B in [SIGMA]) are included in the messages. This is not 
> true for TLS 1.3 with RPKs and TLS 1.3 with RPKs is therefore not 
> SIGMA. TLS 1.3 with RPKs is vulnerable to what Krawczyk’s SIGMA paper 
> calls misbinding attacks:
>
> “This attack, to which we refer as an “identity misbinding attack”, 
> applies to many seemingly natural and intuitive protocols. Avoiding 
> this form of attack and guaranteeing a consistent binding between a 
> session key and the peers to the session is a central element in the 
> design of SIGMA.”
>
> “Even more significantly we show here that the misbinding attack 
> applies to this protocol in any scenario where parties can register 
> public keys without proving knowledge of the corresponding signature key.”
>
> As stated in Appendix E.1, at the completion of the handshake, each 
> side outputs its view of the identities of the communicating parties. 
> On of the TLS 1.3 security properties are “Peer Authentication”, which 
> says that the client’s and server’s view of the identities match. TLS 
> 1.3 with PRKs does not fulfill this unless the out-of-band mechanism 
> to register public keys proved knowledge of the private key. RFC 7250 
> does not say anything about this either.
>
> I think this needs to be clarified in RFC8446bis. The only reason to 
> ever use an RPK is in constrained IoT environments. Otherwise a 
> self-signed certificate is a much better choice. TLS 1.3 with 
> self-signed certificates is SIGMA-I.
>
> It is worrying to find comments like this:
>
> “I'd like to be able to use wireguard/ssh-style authentication for my 
> app. This is possible currently with self-signed certificates, but the 
> proper solution is RFC 7250, which is also part of TLS 1.3.”
>
> https://github.com/openssl/openssl/issues/6929 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fissues%2F6929&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C9adf5463acd5410030f108dc5df809a7%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638488567100151158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=0xFpLQBMR2WNFfSfymCrncd2ZXFBkCK%2FTM0hDgbLAsM%3D&reserved=0>
>
> RPKs are not the proper solution.
>
> (Talking about misbinding, does RFC 8446 say anything about how to 
> avoid selfie attacks where an entity using PSK authentication ends up 
> talking to itself?)
>
> Cheers,
>
> John Preuß Mattsson
>
> [SIGMA] https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24 
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flink.springer.com%2Fchapter%2F10.1007%2F978-3-540-45146-4_24&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C9adf5463acd5410030f108dc5df809a7%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638488567100162137%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6zV0rkm4ape8sWEyIeSPeeSA3Zj3Y3SaKtQnrQ5ZTa4%3D&reserved=0>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls