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

[Achim Kraus <[e-mail]>]

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://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
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]