Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks
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 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 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks
Dennis beat me to making the key point about identity :) There are cases where identity misbinding is possible in similar systems. RFC 8844 describes one such case. However, this is not an inherent failing in TLS, but in the usage context. That weakness was not the result of using raw public keys though. What TLS *says* about this risk is really what we should be considering. It might be enough to say that where TLS does not carry all of the relevant identification information, there is a risk of identity misbinding attacks. This can be mitigated by including additional information about identity in the transcript and checking it for consistency (as RFC 8844 does). On Fri, Mar 29, 2024, at 05:27, Dennis Jackson wrote: > Hi John, > > It depends what you mean by an identity. TLS1.3 ensures the peers agree > on the used RPKs and it doesn't rely on any external proof of > possession to achieve that property. > > How the peers come to trust the RPKs or their corresponding identity is > of necessity left to the application - not dissimilar to how the > application has to decide which root certificates to trust and whether > the leaf certificate is appropriate for the intended connection (e.g. > browsers extract the valid identities from the SAN). > > Best, > Dennis > > On 28/03/2024 15:22, John Mattsson wrote: >> 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 >> >> 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 >> >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks
Hi John, It depends what you mean by an identity. TLS1.3 ensures the peers agree on the used RPKs and it doesn't rely on any external proof of possession to achieve that property. How the peers come to trust the RPKs or their corresponding identity is of necessity left to the application - not dissimilar to how the application has to decide which root certificates to trust and whether the leaf certificate is appropriate for the intended connection (e.g. browsers extract the valid identities from the SAN). Best, Dennis On 28/03/2024 15:22, John Mattsson wrote: 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 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks
On Thu, Mar 28, 2024 at 03:22:05PM +, John Mattsson wrote: > 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: Assuming certificates are issued with strong assurance, which, with DV certificates, is perhaps somewhat questionable. > 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: The SNI extension in TLS allows servers that are the targets of misbinding attacks to detect that the client was trying to communicate with a different system, and in the case of HTTPS, there is also the required "Host:" host header, which again will alert the server to the fact that the client is requesting an unsupported resource. Many operators obtain wildcard certificates, again a server should take measures to ensure that among all the hosts sharing the same DNS suffix, the session was actually intended for it, and not another service endpoint, though in the case of multiple application services on the same machine, that isn't always possible, because SNI conveys just the hostname. > “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.” Note, that, for example, with SMTP the simplest way to direct traffic to someone else's MX host is to publish MX records for one's own domain that specify that MX host. So "misbinding" attacks are not "interesting" in this context. Furthermore, because there are no "cross-origin" issues in SMTP, there is nothing to be gained by misleading a client that it is connected to a service endpoint for which one can control the expected public key binding, when in fact it is connecting to a "victim" service endpoint. And of course how clients learn the association between and endpoint, and the expected raw public key is a rather separate matter from whether public keys or certificates happen to be used. The public key might be pre-shared out of band over a pre-existing bilateral trusted channel between client and server, and proof of possession could be part of that exchange if desired and useful. > 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. If the server rejects unexpected SNI (including absence of SNI), that should close the gap. > I think this needs to be clarified in RFC8446bis. The only reason to > ever use an RPK is in constrained IoT environments. This is much too narrow a use-case. There are other valid scenarios. > self-signed certificate is a much better choice. TLS 1.3 with > self-signed certificates is SIGMA-I. Assuming the client looks at the name in the certificate, which isn't always the case. And that the certificate isn't a wildcard certificate, and the there aren't multiple TLS service endpoints at the same hostname, where redirection from one application service to another, might be a concern... > 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 There are legitimate use-cases for RPKs, including at least some where UKS attacks are not applicable. > RPKs are not the proper solution. RPKs are a solution when obtained from a trusted party, e.g. for connections between machines controlled by the same operator, or SMTP (given MX indirection described above), or in applications where cross-origin attacks don't apply, ... > (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?) PSKs are not generally symmetric. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks
On Thu, Mar 28, 2024 at 4:22 PM John Mattsson wrote: > 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.” > With a bit more context (emphasis my own): Yet, no proof of security of the *STS protocol* exists (see more on this below). 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. (We note that while such “proof of possession” is required by some CAs for issuing a certificate, this is not a universal requirement for public key certificates; in particular it is not satisfied in many “out-of-band distribution” scenarios, webs of trust, etc.) In this case Eve can register A’s public key as its own and then simply replace A’s identity (or certificate) in the third message of STS with her own. B verifies the incoming message and accepts it as coming from Eve. Thus, in this case the STS protocol fails to defend against the misbinding attack. Thus, for the STS to be secure one must assume that a secure external mechanism for proof of possession of signature keys is enforced. *As we will see both the ISO* *protocol discussed in Section 4 and the SIGMA protocols presented here do not* *require such a mechanism.* > > > 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 > > > > 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 > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[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 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
