Re: [TLS] Cipher suite values to indicate TLS capability

[Nikos Mavrogiannopoulos <[e-mail]>]

On 06/08/2012 05:18 PM, Adam Langley wrote:

> On Fri, Jun 8, 2012 at 3:35 AM, Nikos Mavrogiannopoulos <[e-mail]> wrote:
>> If you want to only prevent against the attacker that wants to rollback
>> the session to SSL 3.0, then all you need to do is to perform the proper
>> TLS protocol negotiation, which protects against that. If it doesn't
>> work warn the user.
> Yes, the aim is to prevent an attacker performing a downgrade attack to SSLv3.
> Warning the user assumes that the user can understand what we're
> trying to tell them which is not true here.


It may not be true, but what would you do if the SCSV check fails?
Wouldn't you warn the user? Why do you think he'd better understand that
warning? Most probably he'd say that your browser doesn't work. Let's
try the other one (which doesn't support SCSV and thus wouldn't detect a
possible attack).

>> What happens if we have a buggy server that incorrectly implements the
>> fallback detection mechanism? We define another one?
> The SCSV for the renegotiation indication extension was deployed
> without any serious issues, which is strong evidence that we can
> viably deploy other SCSV values.


Indeed, but this was the case in initial TLS deployments. You rarely
have issues when you implement the protocol you defined, the issues
arise when 3rd parties try to implement their understanding of your
protocol. What if a new server comes out that the SCSV fails for some
random reason? I agree that it helps to mitigate some problem, but my
concern is, does any gain obtained justify the introduced protocol
complexity?

regards,
Nikos