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

Achim Kraus Tue, 19 Nov 2024 00:12:34 -0800

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 thecase 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 maycorrectly choose not to care about the identity. For example, client IoTdevices will still have an IP address when connecting to a server.Naturally, client’s IP address is rarely a reliable identifier becausemost clients have dynamic IP addresses or are behind a NAT. Therefore,libraries such as libCoAP assign the identity "RPK" to all clients whenusing (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 oftrusted public keys and whether you care about detecting and preventingmisbinding.

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 changessuggested to RFC 7250 and a new certificate type is necessary. Thereisn'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 indifferent situations isn't always clear or even relevant. Our paperpresents several potential attack scenarios of server (section 4) andclient (section 5) misbinding when using RPKs for authentication. On abroader note, one example consequence of misbinding that Hugo Krawczykgave in a lecture was:

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

For a long time, like Viktor, I thought all this to be very speculativeand not "interesting". But maybe with drones etc., I think the exampleby Hugo Krawczyk now has practical relevance (for me).

In any case, I think it doesn't hurt to provide guidance on detectingand preventing misbinding where possible. Obviously, the guidance shouldnot deter the use of RPK altogether. The intention of the pull requestto 8446bis is to suggest that endpoints should verify each other'sidentity when they are unique and meaningful (which is at least the casewhen servers use domain names as identities). We can modify the exacttext 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 usingthe

> 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 stronglyintertwined.

>

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 stronglyintertwined.


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.0and 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 aminimum:


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 foranything.


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 signaturekey.”


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
TLS@ietf.org
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 -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org


_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

Reply via email to