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

From: Brian Smith <[email-masked]>
Date: Mon, 01 Mar 2010 08:43:06 -0600

Martin Rex wrote:
> The original purpose of this extension/proposal is to save network
> bandwith on repeated _full_ TLS handshakes between peers and
> where TLS session caching is not available for whatever reason.
>    
Even when session caching is available, this extension is useful, 
because it saves bandwidth when a session ID/ticket expires.
> In order to make clear that collision resistance of SHA-1 is
> perfectly sufficient, I think the hash value should be
> unconditionally truncated to, say, 128-bit (16 octets),
> independent of which hash algorithm is used.  This would
> also answer any question about whether SHA-1 is sufficient. It is.
>    
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. My 
second argument is that having the client and server both calculate the 
hashes using some agreed-to algorithm is unnecessarily complex.
> Btw. the certificate fingerprinting and public key fingerprinting
> algorithms currently also still use SHA-1 (e.g. rfc-5280 4.2.1.2).
>    
RFC-5280 4.2.1.2 just says that SHA-1 is a "common method" for 
generating the subject key identifier and "Other methods of generating 
unique numbers are also acceptable." In other words, it is an opaque 
unique identifier like I am advocating to simplify this extension. (But, 
to be clear, the subject key identifier would not be an acceptable 
identifier to use for caching certificates, because it only identifies a 
public key, not the entire certificate chain.)

Regards,
Brian

---

From: Martin Rex <[email-masked]>
Date: Mon, 1 Mar 2010 21:35:44 +0100 (MET)

Brian Smith wrote:
> 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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 01 Mar 2010 21:44:11 +0100

Brian Smith <[email-masked]> writes:

> unique identifier like I am advocating to simplify this
> extension.

Further, remember that TLS can be used without any X.509 at all (PSK,
SRP, OpenPGP etc).

The main use case for cached info is likely X.509 CA lists and large
X.509 chains, but there could be other things that needs caching for
non-X.509 in the future.

/Simon