Re: [TLS] Rethink TLS 1.3

[Bodo Moeller <[e-mail]>]

Nico Williams <[e-mail]>:

> Watson Ladd wrote:
>


> > It's clear what the security claims of TLS are be: a TLS connection
> > between two parties ensures that data sent between them isn't
> > intercepted or manipulated, and that they are who they claim to be.
> > This is a fairly standard notion, clearly present in research by the
> > late 80's, and intuitively sensible.
>


> It's the standard Internet threat model.  Aside from needing to be
> updated for massive adversay capabilities, the standard Internet threat
> model has held up well.  What hasn't held up is TLS:
>

This is sort of true, and sort of isn't.

If you look at RFC 3552 ("The Internet environment has a fairly well
understood threat model. In general, we assume that the end-systems
engaging in a protocol exchange have not themselves been compromised.
Protecting against an attack when one of the end-systems has been
compromised extraordinarily difficult. [...] By contrast, we assume that
the attacker has nearly complete control of the communications channel over
which the end-systems communicate.") and the goals of TLS according to RFC
5246 ("Cryptographic security: TLS should be used to establish a secure
connection between two parties"), it's true that this can be read as
covering all kinds of attacks, because it is sufficiently vague. But then
if you look at the *specific* examples of attacks in RFC 3552, it becomes
quite clear that classes of attacks including BEAST weren't really
considered back then.

I don't agree with claims elsewhere in this thread that such attacks
violate the premise of RFC 3552 of end-systems being uncompromised.  If a
system is designed to tunnel externally provided data (some of which may be
provided by an attacker) through TLS, this makes it vulnerable to BEAST,
but I think it's a far fetch to call such a system "compromised" by
design.  Yes, "Cross Site Request Forgery" style attacks can be used to
exploit the security weaknesses, but if the protocols were offering secure
channels according to an appropriate definition, then the weaknesses
wouldn't be an issue (even if the attacker can use scripting languages to
partially remote-control the systems under attack).  [Also, if you believe
that POODLE *requires* this attack setting, you just lack imagination. The
*full* POODLE attack assume this setting, but if an attacker can obtain
just a single byte of your password, that's a breakage too.  Cf.
https://www.iacr.org/cryptodb/archive/2003/CRYPTO/1069/1069.pdf for
inspiration for a setting not involving any Javascript or other scripting
language.]

As we know from the cryptographic literature, however, properly formalizing
the needed security properties can be as hard as (or even harder than)
achieving them.  Everyone reading papers dealing with formal security
proofs for cryptographic schemes will, on occasion, have run into some
formally defined security notion that looks quite reasonable at first, but
on closer inspection turns out to have problems -- e.g., assumes something
that is in fact unsatisfiable, or insufficient, or even both.  The security
claims that TLS should fulfill, for example, may seem somewhat clear, but
only if you don't actually go into all the details.

Accordingly, I don't think it is meaningful to blame *either* the threat
model *or* TLS for the shortcomings.  The lack of clearness about the
security goals can reasonably be blamed on both.

Bodo