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

[Viktor Dukhovni <[e-mail]>]

On Mon, Nov 18, 2024 at 08:25:12AM +0200, Mohit Sethi wrote:

> The model detects misbinding in both cases: i) where the received
> public key is verified via DANE, and ii) where the received public key
> is verified from a list of pre-configured keys.

If the preconfigured key is correctly bound to the intended server, it
is unclear what "rebinding" or other problem you have in mind.  As
for client certificates vs. client RPKs there's again no issue.

Client identifies supplied 3rd-party CAs have little value in most
cases, rather, in the rare case that client certificates are used at
all, the relying party typically also controls client cert issuance and
binding of public keys to names.  In such cases, one can dispense with
reliance on stale certificates and instead look up the public key in
the current name binding database, which should be more up to date.

No client identity other than the public key is necessary in such cases,
the public key is an index into a privately maintained ACL, and
3rd-party CAs are not trusted to assert client entitlment.

Yes, one can imagine scenarios where certificates are some sort of
"government-issued id" and the service provided is to a "legal person",
as identified by said government, rather than to a registered customer.
Such services that delegate user authentication to government-issued
ids in the form of certificates, can of course choose to not use RPKs
(which are typically not enabled by default anyway).

> In fact, the existence of misbinding of TLS RPK can easily tested in the
> real-world with OpenSSL using the following command (version 3.2.0 and up):
> 
> > openssl s_client -connect msguru.eu:25 -dane_tlsa_domain "msguru.eu"
> > -dane_tlsa_rrdata "3 1 1
> > F4D9CF3B4E251085A4F3193DAAF3A5141CD95C7109D33C971C3F8F7CEC48CD1B"
> > -starttls smtp -enable_server_rpk
> 
> The above command results in a successful TLS handshake as is evident from
> the output:
> [...]

> However, there is no server msguru.eu listening on port 25. Instead you are
> connected to Viktor's mail server at mx1.imrryr.org which supports server
> authentication with RPKs and has a DANE record published:
> https://www.nslookup.io/domains/_25._tcp.mx1.imrryr.org/dns-records/tlsa/.

See also second block of comments below.  Note that most SMTP deliveries
with STARTTLS are unauthenticated opportunistic TLS, so no RPK is
required to perform "misbinding", just point your MX record hostname, or
IP address of your MX host somewhere else, and you're set (to achieve
nothing in particular).

> Thankfully, most ISPs block outbound port 25 and therefore Viktor's mail
> server is not suddenly going to see a massive spurt in traffic.

There are plenty of connections trying in vain to brute force SASL
logins on ports 587 and 465.  And nothing would be gained by making
"cross origin" requests to my MX hosts that could be made directly
instead.

> The fact that someone can publish a different MX record as their own
> and that the SNI can be used to detect such situation was already
> pointed out by Viktor in his email:
> https://mailarchive.ietf.org/arch/msg/tls/ey_rNTC8Um1OMD5cxjkpZ1OyInQ/.

It seems you've not entirely understood that post, detecting unexpected
SNI is perhaps appopriate in HTTPS (though the "Host:" header would
perhaps be a more easily inspected signal).  In the case of SMTP there
is little reason to bother, because there are no cross-origin issues to
guard against, and MX records already support redirection, no
"rebinding" needed.  Quoting from that post:

    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.

> The lesson here is the same countermeasure for all misbinding attack - be
> explicit about the identities and check them. We have created a pull request
> for 8446bis adding a reference to misbinding attacks and countermeasures
> when using RPK. The goal was to keep the text to a minimum:
> 
> https://github.com/tlswg/tls13-spec/pull/1366

The "lesson" has a specific scope.  There is no problem with RPKs in
SMTP, and TLS is not synonymous web browsing over HTTPS.  Not even all
HTTPS traffic is in scope, because rebinding is of little interest in
machine-to-machine HTTPS with the client not running any scripts from
the server.

I do hope that any proposed text is not overly broad, and does not
negatively impact valid use of RPKs in non-web applications.

-- 
    Viktor.