Re: [TLS] Rethink TLS 1.3

[Watson Ladd <[e-mail]>]

On Mon, Nov 24, 2014 at 8:56 AM, Martin Rex <[e-mail]> wrote:
> Nico Williams wrote:
>>
>> Henrick Hellström wrote:
>>
>>> Yes, but the point I am trying to make, is that if the implied goal
>>> is to make TLS resilient even against BEAST/CRIME style attacks, the
>>> threat model should be defined accordingly. It makes little sense to
>>> ask for cryptographic review of the protocol, if it is inherently
>>> unclear exactly what kind of threats the protocol is designed to
>>> withstand.
>>
>> BEAST/CRIME are dramatic demonstrations of the capabilities of attackers
>> in the Internet threat model.
>
>
> Nope.  BEAST, CRIME and Poodle are pretty boring demonstrations of the
> ridiculous insecurity of WebBrowsers in their default configuration.

So it's possible to get my Paypal login cookie if I browse to a
malicious site on a fully patched browser? Because that's what BEAST
enabled. Are you saying it's fine that SSL v3.0 leaks one byte per
connection? Because that's POODLE. All of this was known in 2004, and
not fixed in TLS 1.2: no action was taken on publicising the
vulnerabilities, and in the case of some of the CBC mode issues,
vulnerable options were left in. If the web browser is inherently
insecure because it runs javascript, where's the exploit?

>
> As I've previously mentioned, TLSv1.2 has an explicit product warning
> label against such Browser fallacies, and explicitly rules out BEAST,
> CRIME and Poodle from the attack model against which TLSv1.2 and
> all prior TLS and SSL protocol versions provide protection.

If TLS provided a secure channel as defined in
https://eprint.iacr.org/2002/059, then the browser wouldn't have a
problem. Workarounds around the lack of an easily provided property
are never a good idea, unless you know exactly what the problems are.
Why are you so dead set against making TLS useful for browsers?
Providing the right properties isn't that hard: the correct thing to
do looks very similar to the wrong thing, except it's correct.

What are the exact security claims of SSLv3.0? Or TLSv1.0?

>
>
> The vulnerability of Web Browsers that attacks like BEAST, CRIME and Poodle
> exploit is called "Cross-Site-Request-Forgery" (CSRF) vulnerability, e.g.:
>
>    https://www.isecpartners.com/media/11961/csrf_paper.pdf

Just because you don't like the Web Security Model doesn't mean it
doesn't exist. In fact, if you read the link you posted you would see
very simple solutions to the CSRF problem, that work unless the
"secure channel" isn't.  By contrast, a web application that uses
cookies for authentication, and is reachable over TLS 1.0 with an
unpatched browser or RC4, is completely vulnerable, and can do nothing
to solve the problem.

Don't believe there is a difference? Go extract an authentication
cookie from a CSRF vulnerable endpoint. You can easily hit the
endpoint and trigger actions, but you won't get the cookie, and so
can't attack other endpoints. CSRF is a confused-deputy issue: a
capability based model would solve it. But we can't end CSRF without
making it impossible to do things like isolate user accounts from
content as protection against XSS, or federate authentication.
Capability

This isn't even about browsers: TLS based VPN solutions also have to
worry about BEAST. Something as simple as programmatic
username-password authentication can be broken if the client
automatically retries on failure. POODLE leaks one byte after a
certain number of connections are broken: are you sure your code never
retries on failure?

We could fix all of this by providing an actually secure protocol.
What's the disadvantage?

Sincerely,
Watson Ladd

>
> and as long as a Browser keeps providing authentication facilities
> for requests supplied by attackers, the vulnerability is wide open,
> independent of the TLS protocol version that is used (SSLv3, TLSv1.0,
> TLSv1.1, TLSv1.2 or TLSv1.3).  Often, browsers will voluntarily supply
> attackers access to CSRF for non-disclosing authentication schemes,
> including TLS client certificate authentication.  So while current
> disclosing authentication schemes make the problems worse, replacing
> disclosing authentation schemes would only make boring demonstrations
> like BEAST and Poodle less likely, but would not address and fix the
> real problem (CSRF) at all.
>
> For many programmatic clients and servers, attacks like BEAST and Poodle
> are completely irrelevant, because the vast majority of these will neither
> execute attacker-supplied active content, nor will they provide
> Cross-Site-Request-Forgery facilities to attackers for free.
>
>
> If there is anything wrong, then it is the current (lack of)
> "Web Security Model" as it exists in common Web Browsers and as
> it exists on a growing number of Web Servers.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin