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

[Viktor Dukhovni <[e-mail]>]

On Tue, Nov 19, 2024 at 08:52:03AM +0200, Mohit Sethi wrote:
> Hi Achim, Viktor,
> 
> Answering to multiple posts in a single email.
> 
> > The provisioning is frequently done "out-of-band" and the trust is
> > based on that procedure.
> 
> As observed from the formal modeling exercise:
> https://arxiv.org/pdf/2411.09770, misbinding is possible even in the case
> where provisioning is "out-of-band".

The paper and the proposed changes to the RFC fail to state that
misbinding is often not *relevant*.  Who cares whether the client knows
some name for the holder of a public key, if (in essence) it is just
trying to to communicate with the holder of a particular key, and the
name is just a way to learn an IP address to reach that holder.

MX hostnames are just a way to *indirectly* learn the IP address of the
SMTP server, and validate its key, but the client had no prior intent
to reach a particular server, and "misbinding" is simply irrelevant.

Yes, there are of course signficant well known application domains where
the misbinding matters (and RPK has seen no use), but there are also
others where misbinding simply does not matter (and where RPK is
starting to get used).

> Viktor wrote:
> 
> >    So "misbinding" attacks are not
> >      "interesting" in this context.
>
> I fully agree with the assertion that the consequences of misbinding in
> different situations isn't always clear or even relevant. Our paper presents
> several potential attack scenarios of server (section 4) and client (section
> 5) misbinding when using RPKs for authentication. On a broader note, one
> example consequence of misbinding that Hugo Krawczyk gave in a lecture was:
> 
> > B and C are fighter jets, and A is their commander. B has been
> > compromised by the enemy. A tells B to self-destruct, but because B
> > mounted a misbinding attack, the command goes to C.

This is dramatic, but not useful.  The point is that scope matters, and
SMTP is NOT the fighter jet command application.  I have no objections
once the claims are not over-generalised to application domains where
they don't apply.  I'd like to see appropriate qualifiers that make it
clear that misbinding isn't always relevant, or may be only relevant
during key enrollment.

> For a long time, like Viktor, I thought all this to be very
> speculative and not "interesting". But maybe with drones etc., I think
> the example by Hugo Krawczyk now has practical relevance (for me).

I have never said that UKS attacks are always a non-issue.  Sometimes
they really matter, and other times they do not matter at all, or
are an issue only during enrollment.

There may be times when you need a sensitive device to display a
matching value derived from a key agreement authenticated by its
purported key, with handshake transcripts...  Securing device
registration to ensure that it is not just proxying the traffic
elsewhere, or just reporting some other key.

This is a registration security problem, once the keys are properly
bound, there's no need to subsequently modify RPK when communicating
with the (fighter plane) device.

> In any case, I think it doesn't hurt to provide guidance on detecting
> and preventing misbinding where possible. Obviously, the guidance
> should not deter the use of RPK altogether. The intention of the pull
> request to 8446bis is to suggest that endpoints should verify each
> other's identity when they are unique and meaningful (which is at
> least the case when servers use domain names as identities). We can
> modify the exact text accordingly.

Only, if the guidance is not so general as to give the misleading
impression that absent novel counter-measures, there is necessarily a
problem.

For example, replacing RPKs with self-signed certificates is not
necessarily a means to improve security.  There are some DANE SMTP
servers whose operators are not careful to make sure that the MX
hostnames they choose match the DNS names inside the deployed
certificates, and this is not a problem with "3 1 1" TLSA records,
for which the SAN is ignored!  But some of the same operators sadly
have "2 1 1" records, and their sloppiness leads to authentication
failure.

The "3 1 1" approach is more robust all around, avoids the need to ever
care about CRLs, hostnames in certificates, expired certificates, ...
and is compatible with RPKs.  One gets more security in practice by
keeping everything as simple as possible.  Introducing CAs, CRLs,
expiration dates, requirements on matching SANs, ... makes the
system both more vulnerable to misissuance (ACME is TOFU) and
more brittle.

-- 
    Viktor.