Re: [TLS] Minutes from Tuesday

[Manuel Pégourié-Gonnard <[e-mail]>]

On 31/10/2014 02:26, Martin Rex wrote:
> Bodo Moeller wrote:
>> I just don't think that the additional benefit (per connection)
>> is worth the additional computational effort (per connection), and the
>> extra latency: for many clients, there is *no* additional benefit at all.
> 
> There is a *HUGE* benefit for clients.  They will be able to properly
> recognize accidental fallbacks that should not have happened in the
> first place.  Otherwise it takes bug reports and several years before
> client connection management failures get fixed.
>
It seems to me the current draft allows that too, so I don't see how your
proposal provides additional value compare to the draft on this exact point.
(I agree it does provide value compared to current situation, obviously).

>> clients will require additional code to handle this properly,
>> whereas reacting to a fatal alert is something that all TLS
>> implementations already know how to do.
> 
> That reaction is called interop failure.  That is the far opposite
> of what IETF working groups are supposed to consciously cause to happen
> when the alternative would be to make interop succeed.
> 
I'm not so sure. There are already a lot of situations where implementations are
requires to make the handshake fail, eg if the verify data from the Finished
message don't match, which indicates the handshake data has been tampered with.
This is not entirely different, the main difference is that the suspected
tampering happened during the previous handshake.

I'm not saying breaking the handshake is the only right thing to do, I can see
the benefits of the solution you suggest, but I think the simplicity of the
current draft is a big advantage in getting it widely (and correctly) deployed
sooner rather than later, which IMO outweighs the advantages of a more complex
approach.

Manuel.