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

[Watson Ladd <[e-mail]>]

Dear all:
I screwed up my reply and Nicos argued it needed to be sent to the list.

On Thu, Apr 17, 2014 at 7:23 PM, Nico Williams <[e-mail]> 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.

Is channel binding really necessary in TLS? I agree key extractors
are, but I think the cases where TLS is layered on encrypted channels
are pretty rare. Of course if TCPcrypt becomes more common this will
change. But I don't see how to do a key confirmation and 1-RTT in the
same handshake: we may end up with options, and then have to be very,
very careful in hashing the handshake. Chalk this up to me neglecting
a usecase.

>
> If one is not doing channel binding then I believe no key confirmation
> is needed.

That's correct: You can't get PFS but only weak PFS. However, weak PFS
is good enough. No two message protocol can achieve PFS.

>
> The Kerberos AP exchange is a clear case of this.  When no CB is used
> what does one gain from key confirmation in Kerberos?  Nothing, IMO.
> If you trust your KDC and the cryptosystem then really, who cares if
> you're feeding ciphertext to a party that lacks the key to decrypt it
> with?
>
> But in the Kerberos GSS mechanism the AP-REP message serves as the
> channel binding confirmation message, so if one is doing CB then
> clearly one also wants that AP-REP.
>
>> Furthermore, this fixes the issue with 1-RTT proposals where a
>> modified handshake might not get detected until data was sent on a
>> downgraded channel.
>
> Only by removing the thing that the modification of which would have
> been detected.  The "issue" remains in some sense, or it was never
> really an issue.  Let's focus on whether and when we need key
> confirmation.

I was completely confused. You can have

C->S: here's my key
S->C: here's my exchange and half of the confirmation
C->S: confirmation and my data.
S->C: response

a 1-RTT handshake in which the Finished message actually protects the handshake.

Sincerely,
Watson Ladd
>
> Nico
> --



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin


-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin