Re: [TLS] Constant Finished (was Re: Kill Finished)

[Michael StJohns <[e-mail]>]

Meant to finish up on this.

On 4/20/2014 4:21 PM, Watson Ladd wrote:
> On Sun, Apr 20, 2014 at 12:54 PM, Michael StJohns
> <[e-mail]> wrote:
>> In some ways, the right answer might be to do a finished signature not over
>> the messages, but over the content of SecurityParameters - with assumption
>> that the SecurityParameters pseudo-structure is extended to provide enough
>> information about offers and acceptances.
> Why bother when we have the transcript which gives us exactly that?

Because, you have to start the transcript before you know which summary 
function you're going to negotiate - e.g. which PRF for the 
cryptosuite.  That gives you some issues with respect to negotiation of 
the PRF (and as we've been talking about an issue doing this for block 
cipher based PRFs)

A signature over the transcript of all messages is really about signing 
the final snapshot state the results from those messages. In an ideal 
world, SecurityParameters would hold all of that state.   AFAIK, 
SecurityParameters currently appears to hold all of the state except 
that generated from extension negotiation. Adding that in would allow a 
single HMAC signature over the SecurityParameters pseudo structure to 
replace the current HASH the messages then HMAC approach used to provide 
the Finished message tag.

As I suggested elsewhere - it really should be possible to build a 
lightweight TLS1.3 system based on PSK and using only the AES block 
encrypt function.  (Or other block encrypt function for other domains).  
To enable this, we either need to get the summary function 
(HASH(handshake_messages)) out of the middle, OR come up with a pretty 
standard block-cipher based hashing mechanism.

The problem with the latter approach is that I'm unable to find a 
"standard" (e.g. issued by IEEE, NIST, X9 etc) block cipher hash 
construct.  There are plenty of academic papers, but nothing that meets 
the "BCP" (Best Commercial Practice) smell test.


> What you propose can work, but if we mess it up it won't be pretty.
> Furthermore, if an extension isn't actually authenticated that's a
> rather big semantic gap. Suppose ALPN wasn't authenticated, and the
> same string could have two different meanings under two different
> protocols. The right answer is never to remove properties TLS provides
> today.

The right answer is to understand what properties you actually get and 
make sure they're providing what you want and need (c.f. heartbeat for a 
counter example).   Even crypto specifications say that it's ok to do 
things in different ways as long as you get the same answers.


>
>