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

[Achim Kraus <[e-mail]>]

Hi Mohit,

 > B and C are fighter jets, and A is their commander. B has been
 > compromised by the enemy. A tells B to self-destruct, but because B
 > mounted a misbinding attack, the command goes to C.

As long as:
- each party uses it's own key-pair
   (that is commonly achieved by generating a key-pair for each)
- all private keys stay private, they are obvious not shared at all
- all public keys are exchanged ahead (out-of-band and in a trustful
   way) so that each fighter knows, which public key authenticates
   each other fighters.

I hardly see the attack.

br
Achiom




Am 19.11.24 um 07:52 schrieb Mohit Sethi:
> Hi Achim, Viktor,
> 
> Answering to multiple posts in a single email.
> 
>> The provisioning is frequently done "out-of-band" and the trust is
>> based on that procedure. 
> 
> As observed from the formal modeling exercise: 
> https://arxiv.org/pdf/2411.09770, misbinding is possible even in the 
> case where provisioning is "out-of-band".
> 
>> I consider, that your statement applies for some use-case, and for
>> others not.
> 
> There typically is always an identity associated with a key. You may 
> correctly choose not to care about the identity. For example, client IoT 
> devices will still have an IP address when connecting to a server. 
> Naturally, client’s IP address is rarely a reliable identifier because 
> most clients have dynamic IP addresses or are behind a NAT. Therefore, 
> libraries such as libCoAP assign the identity "RPK" to all clients when 
> using (D)TLS: 
> https://manpages.ubuntu.com/manpages/noble/man3/coap_encryption.3.html
> 
>>     * NOTE: If using RPK, then the Public Key does not contain a CN, but "RPK"
>>              * is presented for the cn parameter.
> Ultimately, it depends on how you build the local file or database of 
> trusted public keys and whether you care about detecting and preventing 
> misbinding.
> 
>> With that, please keep RFC7250 "as it is" and if you really insist,
>> introduce a new certificate type, which then may be trimmed to the
>> use-case, you have in mind. 
> I don't know how you got the impression that there are some changes 
> suggested to RFC 7250 and a new certificate type is necessary. There 
> isn't. I am also not sure what use-case you are referring to?
> 
> Viktor wrote:
> 
>>    So "misbinding" attacks are not
>>      "interesting" in this context.
> I fully agree with the assertion that the consequences of misbinding in 
> different situations isn't always clear or even relevant. Our paper 
> presents several potential attack scenarios of server (section 4) and 
> client (section 5) misbinding when using RPKs for authentication. On a 
> broader note, one example consequence of misbinding that Hugo Krawczyk 
> gave in a lecture was:
> 
>> B and C are fighter jets, and A is their commander. B has been 
>> compromised by the enemy. A tells B to self-destruct, but because B 
>> mounted a misbinding attack, the command goes to C.
> 
> For a long time, like Viktor, I thought all this to be very speculative 
> and not "interesting". But maybe with drones etc., I think the example 
> by Hugo Krawczyk now has practical relevance (for me).
> 
> In any case, I think it doesn't hurt to provide guidance on detecting 
> and preventing misbinding where possible. Obviously, the guidance should 
> not deter the use of RPK altogether. The intention of the pull request 
> to 8446bis is to suggest that endpoints should verify each other's 
> identity when they are unique and meaningful (which is at least the case 
> when servers use domain names as identities). We can modify the exact 
> text accordingly.
> 
> --Mohit
> 
> On 11/18/24 08:55, Achim Kraus wrote:
>> Hi Mohit,
>>
>> > 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.
>> >
>>
>> I consider, that your statement applies for some use-case, and for
>> others not.
>>
>> Especially for device communication, it is also common to use a rather
>> "private" deployment with ahead provisioned credentials (PSK, RPK).
>> The provisioning is frequently done "out-of-band" and the trust is
>> based on that procedure.
>> For the client-side I also can't see, that the certificate of the
>> client is related to a "domain-name", at least it's in my opinion
>> not a "public" domain-name.
> 
> 
> 
>>
>> With that, please keep RFC7250 "as it is" and if you really insist,
>> introduce a new certificate type, which then may be trimmed to the
>> use-case, you have in mind.
>>
>> br
>> Achim
>>
>>
>>
>>
>> Am 18.11.24 um 07:25 schrieb Mohit Sethi:
>>> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fpdf%2F2411.09770&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C382b365d77294342590f08dd079e1485%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638675098011653679%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=m1WHWu6x4Mji1I3V5lDx%2F1xsp9wkEll7lXATML0dZaE%3D&reserved=0. 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nslookup.io%2Fdomains%2F_25._tcp.mx1.imrryr.org%2Fdns-records%2Ftlsa%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C382b365d77294342590f08dd079e1485%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638675098011672455%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=5fOcEehL0Jvs%2BpWSfnMg48AgWguHbCHzEebbLtnOc2c%3D&reserved=0. 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2Fey_rNTC8Um1OMD5cxjkpZ1OyInQ%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C382b365d77294342590f08dd079e1485%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638675098011685911%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=PZvTQjjMyNngU8UwXtczBy6L3GIFxv7tWO36uP8c%2Bvc%3D&reserved=0.
>>>
>>> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Ftls13-spec%2Fpull%2F1366&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C382b365d77294342590f08dd079e1485%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638675098011699130%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=mhVDtiV57hO5rQtTtx%2FCvKg0EJgvy52PNxZ%2BpHOfg1o%3D&reserved=0
>>>
>>> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fissues%2F6929&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C382b365d77294342590f08dd079e1485%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638675098011711560%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=fhVNHXyapg6cwMt3ULeBI44%2B0c%2B7UIe%2Fir3%2BzzfKOm8%3D&reserved=0
>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fissues%2F6929&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C382b365d77294342590f08dd079e1485%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638675098011724475%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=OK9zJywpgVUjciYWA%2B%2FXU41PW0nxPN2OO5ApHfueeaE%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://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%7C382b365d77294342590f08dd079e1485%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638675098011736175%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=OodiXeD%2FyOFd20muZPVfqhRpNXtlYYOHqyho%2F4dBcb4%3D&reserved=0
>>>> <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%7C382b365d77294342590f08dd079e1485%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638675098011748055%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=YVWhb%2FnkjnMAhaIMYZOgBH6KgQPY2UPlO09ggTmepA8%3D&reserved=0>
>>>>
>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> [e-mail]
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C382b365d77294342590f08dd079e1485%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638675098011759747%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=kzIwp6tblZWGoLhmy87B%2BAd8psnNqxUFVSYgFJDIYjs%3D&reserved=0
>>>
>>> _______________________________________________
>>> TLS mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>