On Thu, Mar 28, 2024 at 4:22 PM John Mattsson <john.mattsson= 40ericsson....@dmarc.ietf.org> 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
