Re: [TLS] An SCSV to stop TLS fallback.

[Ralf Skyper Kaiser <[e-mail]>]

Hi Yaron,

TLS Version Pinning:
I do not have a solution for the cluster situation but I assume that the
same problem exists for pinning of the certificate. It should be solved the
same way.

I think this would solve the fallback issue in an elegant way with a
feature that is anyway already coming to the browsers and without protocol
modifications.

CIPHER-SUITE Pinning:
We are already making the judgment call which ciphers are NULL, WEAK and
STRONG. If I use 'STRONG' on my first connect I would not like to be
downgraded to WEAK even that in general I would like to have weak enabled
in my browser for other websites.


regards,

ralf



On Sat, Dec 7, 2013 at 10:40 AM, Yaron Sheffer <[e-mail]>wrote:

> Hi Ralf,
>
> I like the idea of pinning the version number, but I don't think it will
> work well in clusters without significant tinkering (i.e., protocol
> changes): the client connects to cluster member A which has just upgraded
> to TLS 1.3 and immediately pins that server to 1.3. Now it connects to
> another cluster member which is still on TLS 1.2, and the connection is
> reset.
>
> I don't understand how you could pin "ECDHE" - you would need to define
> whether DHE is better or worse than ECDHE, and I don't think we want to
> make that judgment call.
>
> Thanks,
>         Yaron
>
>
> On 12/07/2013 12:31 AM, Ralf Skyper Kaiser wrote:
>
>> Hi,
>>
>> the draft only concerns HTTPS (no other client side implementation
>> attempts a reconnect when it receives
>> a RST on  TLS 1.x [which is bad to start with but apparently necessary]).
>>
>> A solution that solves some of the mentioned problems without any
>> protocol change is
>> to pin the TLS version the same way as certificates are pinned. And
>> while pinning the TLS
>> version it should also be considered to pin the cipher suite ("Use this
>> cipher suite or
>> a better one").
>>
>> After first connect the client will not allow any lesser security (TLS
>> 1.3, ECDHE, ..) than the one
>> used on last connect.
>>
>> regards,
>>
>> ralf
>>
>>
>> On Wed, Nov 27, 2013 at 1:42 AM, Brian Smith <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>      >   In the event that a client is making a fallback connection, it
>>      > includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
>>      > current server which sees this cipher suite in a ClientHello SHOULD
>>      > return a fatal alert, inappropriate_fallback (86) and abort the
>>      > connection.
>>
>>     Adam, I think what you propose makes sense. However, I think it might
>>     not be ideal if there are any circumstances where the browser could
>>     accidentally fall back to a lower version--e.g. falling back after a
>>     timeout or falling back in response to the connection being reset.
>>     AFAICT, we currently have to do fallback from TLS 1.2 -> TLS 1.1 and
>>     from TLS 1.1 -> TLS 1.0 in response to connection resets. There will
>>     be some false positives here. In addition to potentially reducing the
>>     security of the connection, these fallback connections add a lot of
>>     latency. If we attempt a fallback connection in response to a
>>     connection reset, and we receive an inappropriate_fallback alert, then
>>     we'd have to make yet *another* connection without the fallback. All
>>     other things being equal, it would be better if the server could
>>     respond respond exactly as it would with a TLS 1.2 ClientHello,
>>     without downgrading the cipher suite or any other feature, more like
>>     what Martin Rex suggested.
>>
>>     However, I don't think it is realistic to backport features all the
>>     way to SSL 3.0. The information in the TLS extensions is too
>>     important, and trying to define good defaults for missing extensions
>>     that make sense long-term seems like it will just bind our hands too
>>     much in the future.
>>
>>     So, we should could consider backporting TLS 1.2 cipher suites to TLS
>>     1.1 and TLS 1.0, but then using your suggested inappropriate_fallback
>>     for for SSL 3.0 handshakes only.
>>
>>     Whether this complication is justified depends on how frequently we
>>     receive false-positive connection resets (and anything else that can
>>     be a false positive) and how much we care about optimizing performance
>>     for that case.
>>
>>     Cheers,
>>     Brian
>>     --
>>     Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
>>     _______________________________________________
>>     TLS mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/tls
>>
>>
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>  _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>