Subject: Re: [TLS] New "Fast-Track" draft posted

From: Russ Housley <[email-masked]>
Date: Fri, 10 Apr 2009 11:10:10 -0400

Eric,

I'm not quite sure how this approach works out with the extension 
negotiation mechanism.

 From the shorthand here, I'm assuming that the client offers the 
cached_information extension in the ClientHello, and if the Sever 
indicates support for it in the ServerHello, then the client sends 
CachedInformation.  So, if the server indicates support because it 
has code for certificate_chain(1), then the client sends 
yet_to_be_specified_stuff(48), then the negotiation has not helped 
because the granularity of the negotiation does not align with the 
potential information that the client is considering.

Russ

On 4/7/09 5:46 PM, "Eric Rescorla" <[email-masked]> wrote:

 > Stefan,
 >
 > As we discussed in SFO, I think this is a good idea, but I would
 > generalize it a bit. Your current syntax only supports cert
 > caching. I would add one more level of indirection:
 >
 >       enum {
 >            cached_information(TBD), (65535)
 >       } ExtensionType;
 >
 >       enum {
 >            certificate_chain(1), trusted_cas(2), (255)
 >       } CachedInformationType;
 >
 >       struct {
 >            HashAlgorithm hash;
 >            opaque hash_value<1..255>;
 >       } CachedInformationHash;
 >
 >       struct {
 >            CachedInformationType type;
 >            CachedInformationHash hashes<1..2^16-1>;
 >       } CachedInformation;
 >
 > Note that this also supports the minimal level of hash agility
 > we discussed in the meeting.
 >
 > -Ekr
 >
 >

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 10 Apr 2009 19:00:20 +0200

Russ,

No this is not the way I originally intended the logic, and how I think Eric
meant either.

The client send the cashed information in the ClientHello, not after the
server response.

The server includes the hashes of the cashed information types it supports
in the ServerHello.

So, if the server responds with the hash of cashed information type 1 but
not the hash of the cashed information type 2, then the client will assume
that only the cashed information of type 1 matches and is supported by the
server.

Does this make sense?

/Stefan

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Apr 2009 14:04:54 -0400

Stefan:

Thanks.  That makes a lot more sense.

Russ