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

[Mohit Sethi <[e-mail]>]

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]
>