Re: [TLS] Deprecating SSLv3

[Henrick Hellström <[e-mail]>]

On 2014-11-24 23:45, Nico Williams wrote:
>> CRIME, BEAST, POODLE, they all depend on my browser going to
>> http://www.attacker.com, and then a script loaded from that site
>> running on the browser, sending requests to Facebook and google and
>> the like with *my* cookies. For some reason these requests are treated
>> as if they come from *me* rather than the attacker. They call it CSRF,
>> but it’s not really forgery. It’s just the way the web is built.
>
> Oh sure, and I agree fully, we could totally have a bash-the-web-
> security-model thread :) but we can't really do anything about it from
> TLS WG.

The TLS WG might define a formal threat model that can be backed up by 
both, on one hand, the cryptographic protocol design, and, on the other 
hand, the security analysis section of the main RFCs that outline 
correct usage in layman's terms. Obviously there SHOULD be a straight 
logical connection between the cryptographic design, the formal threat 
model and the security analysis sections. Otherwise TLS is broken.

Conversely, if TLS WG does this and browsers violate the implementation 
instructions in the security analysis section, the browsers are broken. 
In such a scenario some browser manufacturers and website publishers 
would probably fix the errors at the expense of some interoperability 
issues and some functionality loss, while others would ignore the issues.

The point is, that it is hard to justify that the TLS WG should output 
standards that are not based on a coherent security analysis, just 
because sites like Facebook, Google, EBay, PayPal etc, have a vested 
interest in letting third party web publishers distribute fourth party 
javascript that logs in to their servers with the credentials of the 
client users, and claim this is "secure" just because it is done over 
HTTPS and not in direct conflict with the explicit recommendations of 
the TLS WG.