Re: [TLS] Wrapping up cached info (and PRF WTF)

["Kemp, David P." <[e-mail]>]

>> [Nico] Paul Hoffman proposes an extension to add inputs to the
Finished 
>> message computation.  There's no objection yet to Paul's proposal on 
>> the grounds you state.
>
> [Marsh] I'm not sure the discussion got that far, so it's not evidence
of much.


Was this a verbal proposal?  Paul has submitted the following I-Ds:

draft-hoffman-tls-additional-random-ext-01  -- Additional Random
Extension to TLS
draft-hoffman-tls-master-secret-input-01    -- Additional Master Secret
Inputs for TLS

but nothing that would add inputs to the Finished computation other than
what was actually transmitted over the wire.

I agree with using a checksum to identify the cached data while
including the actual data in the finished calculation.   I don't see any
mechanism for doing that using either of the Hoffman drafts, but I still
think it could be done in a relatively straightforward manner by
defining a "CachedObject" compression algorithm that would "compress"
and "expand" by direct substitution of checksums for data.

----------

And on a different topic, What is This Function?


RFC 5246 section 4.3 defines the notation for two types of vectors:
  Fixed length:     T T'[n];
  Variable length:  T T'<floor..ceiling>;

and section 7.4.9 defines the structure of the Finished message:

      struct {
          opaque verify_data[verify_data_length];
      } Finished;

      verify_data
         PRF(master_secret, finished_label, Hash(handshake_messages))
            [0..verify_data_length-1];


What sort of notation is a function PRF() followed by a floor and
ceiling expression enclosed in square brackets []?

Assuming it means that the PRF output is truncated to some variable
number of bytes, why is the floor 0 bytes and the ceiling 11 bytes when
all verify_data vectors MUST be either exactly 12 (current ciphersuites)
or at least 12 (future ciphersuites) bytes???

Dave



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Joseph Salowey (jsalowey)
Sent: Monday, May 17, 2010 12:30 PM
To: Marsh Ray; Blumenthal, Uri - 0668 - MITLL
Cc: [e-mail]
Subject: Re: [TLS] Wrapping up cached info

I agree with Uri, that if you determine you need SHA-256 then you should
plan for hash agility.  TLS 1.2 plans for hash agility.  

What about Nico's proposal where a checksum is used to identify the
cached data and the actual handshake contains the actual data hashed
with the algorithm used in the PRF negotiated with the cipher suite? 

This way we don't have to introduce hash agility into the extension, but
we have cryptographic hash agility where it matters in the Finished
computation.  Does it solve the problem?  

Joe