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

[Viktor Dukhovni <[e-mail]>]

On Thu, Mar 28, 2024 at 03:22:05PM +0000, 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.