Re: [TLS] Rethink TLS 1.3

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

On 2014-11-22 23:15, Watson Ladd wrote:
> On Sat, Nov 22, 2014 at 3:31 AM, Henrick Hellström <[e-mail]> wrote:
>> On 2014-11-22 01:57, Watson Ladd wrote:
>>>
>>> Was the TLS 1.3 draft written by a cryptographer? No.
>>> Has it been reviewed by cryptographers? Unclear.
>>> Are the mechanisms secure? Unknown.
>>> Is it easy to analyze TLS 1.2? No.
>>> Was TLS 1.2 secure? No.
>>> Has TLS 1.3 fixed flaws in TLS 1.2? Some: session_hash remains
>>> unincluded, but the record layer is finally fixed.
>>
>>
>> I think such discussions would benefit from the basic premise that "secure"
>> is a relative notion. It is completely pointless to ask if a protocol is
>> secure or not secure, unless you first present an exhaustive list of
>> security claims. That is, you can't ask if TLS 1.3 is secure or not, without
>> first describing what security is to be expected from different scenarios.
>
> 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.
>
> Of course, past versions of TLS haven't provided it.

OK, but in such case, the problem with BEAST would be the browser 
implementation dependent violation of same-origin policy constraints, 
and not part where the CBC state is predicted. Your requirements imply a 
strict same-origin policy. If such a policy is violated, the problem is 
that SSL/TLS is used in a scenario that transcends its security claims, 
and not that the protocol is flawed.