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 <tls-boun...@ietf.org> *On Behalf Of *John Mattsson
*Sent:* Thursday, March 28, 2024 4:22 PM
*To:* TLS@ietf.org
*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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
