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

[Adam Langley <[e-mail]>]

On Thu, Feb 18, 2010 at 8:41 AM, Stefan Santesson <[e-mail]> wrote:
> I think this is NOW ready for WGLC

Wan-Teh Chang and I went over this draft yesterday and we sketched up
some changes to the draft that we think might be a good idea.

In outline:
   1) The extension is symmetrical, so the server can now predict
values from the client.
   2) Both sides can list the types of objects for which they support caching.
   3) Both sides can list the hash types which they support.
   4) Substitution of cached values now involves new handshake message types.
   5) Made it clearer that each substitution is optional and independent.

I don't feel particularly strongly about any of these points and would
much rather see the current draft than nothing at all.

1) makes the extension symmetrical and it seems like there might be
something in the future that the server would like to predict from the
client. At the moment we suggest that the server might want to support
predicting the client's certificate. Often a CertificateRequest
handshake is a renegotiation and a higher level knows what certificate
the client should be presenting.

2) was a suggestion from Martin Rex and 3) is a follow on from that.

4) results from the fact that I don't think the current draft is clear
enough about how the substitution occurs. Making new handshake types
means that everything is very explicit and I prefer that. However, I
can't think of anything technically wrong with just memcmp()ing for
the hash values in the existing handshake messages, if it was
precisely specified.

Cheers

AGL


3.  Cached Information Extension

   A new extension type (cached_information(TBD)) is defined and used in
   both the client hello and server hello messages.  The extension type
   is specified as follows.

   enum {
        cached_information(TBD), (65535)
   } ExtensionType;

   The "extension_data" field of this extension, when included in the
   client hello, SHALL contain "CachedInformation" according to the
   following structure:

   enum {
        server_certificate_chain(1),
        client_certificate_chain(2),
        trusted_cas(3),
        (255)
   } CachedInformationType;

   struct {
        HashAlgorithm hash;
        opaque hash_value<1..255>;
   } CachedInformationHash;

   struct {
        CachedInformationType type;
        CachedInformationHash hashes<1..2^16-1>;
   } CachedObject;

   struct {
        CachedInformationType supported_types<0..255>;
        HashAlgorithm supported_hash_algorithms<0..255>;
        CachedObject cached_info<0..2^16-1>;
   } CachedInformation;

   Hash algorithm identifiers are provided by the RFC 5246 [RFC5246]
   HashAlgorithm registry.  Compliant implementations MUST support
   sha1(2) as HashAlgorithm.

   When CachedInformationType identifies server_certificate_chain or
   client_certificate_chain, then hash_value MUST include at least one
   hash value calculated over the certificate_list element of a
   Certificate message.

   When CachedInformationType identifies trusted_cas, then hash_value
   MUST include at least one hash value calculated over the
   certificate_authorities element of a server side CertificateRequest
   message.

   Implementations MUST NOT include hashes for multiple objects in the
   same CachedObject structure.  If more than one hash is present in the
   CachedObject structure, they MUST be hashes over the same information
   object using different hash algorithms.

   Implementations SHOULD NOT emit duplicate CachedInformationHashs
   (i.e. the same hash twice).

   Implementations SHOULD NOT emit duplicate CachedObjects (i.e. the
   same object twice).

   supported_types enumerates the set of objects that the peer might
   wish to cache.  This is advisory and may guide the peer when deciding
   whether to cache a given piece of information.  A host may still
   choose to substitute a cached object even if supported_types suggests
   that it is not able to.  There SHOULD NOT be any duplicates in the
   vector.

   supported_hash_algorithms enumerates the set of hash functions that
   the host supports.  Peers may use this to avoid sending hashes using
   an algorithm that is not supported.  This is advisory only, thus a
   host MAY substitute a hash value even if supported_hash_algorithms
   suggests that it is not able to.  There SHOULD NOT be any duplicates
   in the vector.

   Other specifications MAY define more CachedInformationType types.


4.  Message flow

   Clients MAY include an extension of type "cached_information" in the
   (extended) client hello.  Clients MAY need the ability to cache
   different values depending on other information in the Client Hello
   that modify what values the server uses, in particular the Server
   Name Indication [RFC4366] value.

   Servers that receive an extended client hello containing a
   "cached_information" extension, MAY indicate that they support
   caching of information objects by including an extension of type
   "cached_information" in their (extended) server hello.  The server's
   extension may predict values from the client, specifically the
   client's Certificate message, if any.

   Following a successful exchange of "cached_information" extensions,
   implementations may choose to substitute handshake messages as
   follows:

   A Certificate message MAY be replaced with a CertificateHash(TBD)
   message:

   struct {
        HashAlgorithm hash;
        opaque hash_value<1..255>;
   } CertificateHash;

   A CertificateRequest message MAY be replaced with a
   CertificateRequestHash(TBD) message:

   struct {
        ClientCertificateType certificate_types<1..2^8-1>;
        SignatureAndHashAlgorithm
          supported_signature_algorithms<2^16-1>;
        HashAlgorithm hash;
        opaque hash_value<1..255>;
   } CertificateRequestHash;

   In each case, the hash and hash_value fields MUST come from the
   peer's list, as provided in its "cached_information" extension.

   The handshake protocol will proceed using the cached data as if no
   handshake message substitution had occured.  The Finished message
   will however be calculated over the actual data exchanged in the
   handshake protocol.


5.  Examples

   Consider the following handshake message that the server would
   typically transmit:

   0b                 # Handshake message type 11 (Certificate)
   00 00 10           # Handshake message length 16
   00 00 0d           # certificate_list length
   00 00 04           # ASN1.Cert length
   01 02 03 04        # certificate 1 bytes
   00 00 03           # ASN1.Cert length
   05 06 07           # certificate 2 bytes

   In order to predict this message, a client could send the following
   cached_info extension value:

   00 00 19           # cached_info length
   01                 # type (server_certificate_chain)
   00 16              # hashes length
   02                 # hash type (SHA1)
   14                 # hash length (20 bytes)
   8c 4b 89 c9 1c 6d 70 ef 07 53 bf c7 97 c1 ff e6 93 f0 6b 0c

   Where the SHA1 value is the hash of the following bytes:

   00 00 04
   01 02 03 04
   00 00 03
   05 06 07

   If the client correctly predicted the certificate data, and the
   server chose to substitute its Certificate message, then it would
   emit the following CertificateHash:

   xx                 # Handshake message type TDB (CertificateHash)
   00 00 16           # Handshake message length 22
   02                 # hash type (SHA1)
   14                 # hash length (20 bytes)
   8c 4b 89 c9 1c 6d 70 ef 07 53 bf c7 97 c1 ff e6 93 f0 6b 0c


6.  Security Considerations

   Hash algorithms used in this specification are required to have
   reasonable random properties in order to provide reasonably unique
   identifiers.  No serious security threat requires selected hash
   algorithms to have strong collision resistance.


7.  Acknowledgements

   This is substantially the work of S. Santesson (3xA Security).
   However, since he has not reviewed this deriviative version he is not
   listed as an author in case that mistakenly suggests his endorsement.


8.  IANA Considerations

   1.  Create an entry, cached_information(TBD), in the existing
       registry for ExtensionType (defined in RFC 5246 [RFC5246]).

   2.  Create entries for CertificateHash(TBD) and
       CertificateRequestHash(TBD), in th existing registry for
       HandshakeType (defined in RFC 5246 [RFC5246].

   3.  Establish a registry for TLS CachedInformationType values.  The
       first entries in the registry are server_certificate_chain(1),
       client_certificate_chain(2) and trusted_cas(3).  TLS
       CachedInformationType values in the inclusive range 0-63
       (decimal) are assigned via RFC 5226 [RFC5226] Standards Action.
       Values from the inclusive range 64-223 (decimal) are assigned via
       RFC 5226 Specification Required.  Values from the inclusive range
       224-255 (decimal) are reserved for RFC 5226 Private Use.


9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.