Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft

[Martin Rex <[e-mail]>]

Brian Smith wrote:
> 
> Nobody ever said SHA-1 is insufficient. My first argument is that some 
> implementations don't have to implement SHA-1 for any reason, so forcing 
> them to implement SHA-1 just for this extension is unreasonable.

Mandating a single common algorithm for interop appears very reasonable
to me.  Looking at the installed base, the relevant specs to which this
extension applies and the security requirements, SHA-1 looks like a
perfect match (a slightly truncated hash value probably even more so).

How about the same approach that TLSv1.x has been taking all the
time in Section 9:

   In the absence of an application profile standard specifying
   otherwise, an implementation compliant to this document
   MUST implement hashes based on SHA-1 and MAY implement
   hashes based on SHA-256.


If someone had argued that we should not require in an IETF protocol
15 years ago, because it was not universally available, then this
could have been a valid discussion topic, but 2010, this is a
complete no-issue.  Every codebase of TLS has access to SHA-1 today,
and if you are worried about some years from now -- there is no
problem of using an implementation of SHA-1 from a non FIPS 140-X
module for the purpose of this extension, and such code is
widely available.


>
> My second argument is that having the client and server both calculate
> the hashes using some agreed-to algorithm is unnecessarily complex.

I disagree.  Using the hash to signal availability of data cached
from previous handshakes is

  - the most conservative approach to consumption of network bandwidth

  - a very robost approach to detect changes of the real data

  - a minimal impact on the TLS state engine when there is no
    requirement to precompute handshake data of future handshake
    messages during creation of ServerHello.

  - simplicity of the extension architecture/semantics.

You have to look at all handshake scenarios and how they are
affected by this extension, including TLS session resumes,
handshakes with servers that do not support this extension,
and handshakes where the server supports caching of substantially
more distinct handshake data than the client.

When using the hashes over real handshake data that was sent
by servers, then these references to cached data will only get
sent for data that clients have cached from a previous full
handshake with a server that has confirmed to support caching
of that particular data.


-Martin