[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks
From:       "Martin Thomson" <mt () lowentropy ! net>
Date:       2024-03-29 1:43:20
Message-ID: f3f4ddcb-e852-4a1e-a32f-4f7f274d7bf0 () betaapp ! fastmail ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]