Re: [TLS] Finished stuffing

[Benjamin Kaduk <[e-mail]>]

On 09/09/2016 03:19 PM, Ilari Liusvaara wrote:
> On Fri, Sep 09, 2016 at 02:50:59PM -0500, Benjamin Kaduk wrote:
>> I made a few notes on the pull request.  Generally, I support the
>> change, but I get the sense that it may aid the cryptographic properties
>> if we keep the resumption_context and do not overload the resumption_psk
>> as much.
> One problem with this is that authentication_methods can include
> nontrivial methods even for "static" PSKs, and if server takes such
> method, you have an attack unless you bind the PSK secret used. And
> "static" PSKs don't have resumption_context.

Agreed.

>  
> And I would expect that someone will be crazy enough to try to
> provision "static" PSK with the information required to perform
> 0-RTT (ALPN (or indication there is none) and associated cipher)...

Wasn't Hannes just asking about that? ;)

>> I have a slight (i.e., unjustified) preference for doing
>> ClientHello-with-block-of-zeros rather than prefix-of-ClientHello.  (Is
>> there a reason to require this extension to be the last one with
>> block-of-zeros?  Clearly there is for prefix-of-ClientHello.)
> What about the case where client tries DHE-PSK and gets attempt
> rejected because of missing group (or because address verification)?
> 0-RTT is gone yes, but the PSK attempt isn't.
>
> What happens to the hash in this case?
>
>

I feel like I must be missing something, but I don't really understand
the question.  (Sadly, waiting in the hope that someone else did
understand and would respond didn't work.)  The 0-RTT failed, so the
full handshake will have an actual Finished message, with a different
hash calculated (including over the "hello_finished" extension).  The
most plausible way I could interpret the question seems to be asking
about the lack of Hash(resumption_context) in the 1-RTT Finished, but
the security properties of that should be the same as for the
hello_finished, so I'm still puzzled.

Sorry for being dense...

-Ben