Re: [TLS] Kill Finished (and other tricks for hardware)

[Andy Lutomirski <[e-mail]>]

On 04/17/2014 07:23 PM, Nico Williams wrote:
> On Thu, Apr 17, 2014 at 8:35 PM, Watson Ladd <[e-mail]> wrote:
>> On Thu, Apr 17, 2014 at 6:10 PM, Nico Williams <[e-mail]> wrote:
>>> This would require updating the tls-unique channel binding (which the
>>> resumption bug doesn't: just fix resumption).
>>
>> You have a master key: do another extraction from it. I don't see this
>> as unsolvable.
> 
> I was pointing out a fact.  Clearly it's solvable.
> 
>>> Also, are you proposing to have no message which demonstrates
>>> possession of the shared master secret immediately after being able to
>>> compute it?
>>
>> Yes. Key confirmations are useful in extremely limited circumstances.
> 
> Are key confirmations cargo cult?  It depends:
> 
> If one is doing channel binding then a channel binding confirmation
> -which might look much the same as key confirmation- is needed.  The
> reason is that the point of CB is to leave encryption to the
> lower-layer channel, but only if there was no MITM there.
> 
> If one is not doing channel binding then I believe no key confirmation
> is needed.

Playing the devil's advocate:

Suppose I'm using client certificates and I have a server that takes
some action as soon as an authenticated client connects.  Without some
kind of key confirmation, this stops being secure.

Fixing it may be as simple as having the client send an empty record
after the handshake.

I don't see this being a problem in the other direction.  Without key
confirmation, a MITM could trick a client into thinking it connected to
the server, and the client wouldn't notice until it sent some data and
never gets any response.  But even with key confirmation, a MITM can do
more or less the same thing, just by severing the connection after the
handshake.

--Andy