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
