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

[Michael StJohns <[e-mail]>]

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.

_____________________________________________________

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.

So something like:

if MAC is a CMAC then
      verify_data = MAC (handshake_key, MAC (0, 
handshake_messages))[0..verify_data_length-1];
else
     verify_data = MAC (handshake_key, HASH 
(handshake_messages))[0..verify_data_length-1];


Mike


>
> Mike
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>