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

[Watson Ladd <[e-mail]>]

On Fri, Apr 18, 2014 at 7:44 AM, Michael StJohns <[e-mail]> wrote:
> Edited and comments in line.
>
>
> On 4/18/2014 1:59 AM, Michael D'Errico wrote:
>>
>> Watson Ladd wrote:
>>>
>>>
>>> So I propose the following changes:...
>>>
>>> Finished dies.  .........
>>
>>
>> This is a much weaker failure indication than checking the Finished
>> messages, so I'd prefer to keep them.  Can you think of an alternate
>> construction for the Finished message that doesn't use the PRF?
>
>
> The simplest thing here is to use the negotiated PRF algorithm
> (SecurityParameters.prf_algorithm, not the TLS PRF wrapper around that
> algorithm) directly, but key it with a different key than the master secret
> that would also be derived from the pre-master secret.

This still has the key-dependent encryption issue. If we fix the key
generation, the finished messages can be constants.
If we need to use finished messages related to keys, then for
technical reasons verification gets hard.

I'm not an expert on this matter: I only had it explained to me at
DIAC '13 by someone. I don't know how the miTLS paper deals with it,
or if new methods can avoid it. There are key-confirmation messages
that do not have this issue.

It does fix your hardware issue though.
>
> _____________________________________________________
>
> draft-stjohns-tls-tls13-crypto-infra has the complete details on what I'm
> proposing along with the above.  It recommends doing a straight MAC over the
> handshake data, but I realized last night that that might not (will not?) be
> possible as you may not (will not?) have the derived key you're going to
> need for this until later in the processing.  You'd have to keep a copy of
> the negotiation messages around until you acquired the other side's random
> data (e.g. on the client side until you heard ServerHello).  So having some
> sort of summary function is going to be necessary.    We know how to do this
> for hash-based (e.g. HMAC) MACs (use the underlying hash directly), but
> would have to define something for a block-cipher (e.g. CMAC) MAC to do the
> summary function - probably using the CMAC with a zero key.

There is a problem here: CMAC is a MAC, not a hash. In particular, I
can make collisions in CMAC(0, message) trivially, by letting m_1' be
the decryption of m_2+m_2'.

Sincerely,
Watson Ladd

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