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

From: huangmin <[email-masked]>
Date: Fri, 10 Apr 2009 15:05:22 +0800

Hi,Stefan

I also have the same consideration as Martin about actions of caching, updating and/or replacing the certificate path taken by the client.  I think there may be not much necessary to collect/cache more than one certificates. In TLS Handshake process,server would treat the same client(or the same kind of clients) in the same way, which means that the server would like to send the same certificate or certificate path to the same client(or the
 same kind of clients) all most of the time. And I imagine this is the most general case in practice. 

If collect/cache more than one certificate paths, take certificate renewal into account, client will both cache the old(revocation) certificate path and the new certificate path(in fact, the old certificate path has turn to be redundant now), there will be a revocation mechanism of certificate hashes required,or the client would send the more and more hash values everytime when it do TLS handshake with the same server. This is just one exam
ple. That is, when client is designed to collect/cache more than one certificate paths, it may hold some useless/not much useful certificate paths, and send them to the sever during every TLS handshake. There should be some methods, which may be complex, to deal with it. So, why not collect/cache just one certificate path of the server?

In addition, here is another question, the server would send the hash of the certificate path contained in the extension of the server hello message, and then again in the server certificate message. The aim is to inform and be checked the client that the cached certificate path is valid, so once must be enough, do you think sending the same hashes twice from server to client is redundant?

regards,
Min Huang

----- 原始邮件 -----
发件人: Stefan Santesson <[email-masked]>
日期: 2009年 3月 13日, 星期五,  上午2:16
主题: Re: [TLS] New "Fast-Track" draft posted
收件人: [email-masked]
抄送: [email-masked], [email-masked]

> Martin,
>  
>  Thanks for your extensive feedback. Comments in-line.
>  
>  /Stefan
>  
>  
>  On 3/10/09 5:54 PM, "Martin Rex" <[email-masked]> wrote:
>  
>  > Stefan Santesson wrote:
>  >> 
>  >> I included the possibility for the client to send more than one 
> hash simply
>  >> because I was not sure that there are no situation where that 
> could be
>  >> useful.
>  >> 
>  >> So as the text is written now, the client may include a number of 
> hashes,
>  >> matching different sets of server certificate paths. This may for 
> example be
>  >> 2 hashes for the same server certificate calculated over different
>  >> certificate paths.
>  >> The server will compare the hashes against the hash of the 
> certificate path
>  >> it intended to send. If there is a match, the server will indicate 
> the
>  >> omitted path by including the corresponding hash in its Hello message.
>  > 
>  > 
>  > I think the peculiarities of the caching of the "server 
> certification path"
>  > should be described with a few examples in order to make it clear what
>  > is actually meant here.  At first, I was wondering why a client would
>  > collect/cache more than one certification path as "valid" in the 
> first place.
>  > 
>  
>  Agree, I think it is reasonable to make such clarification.
>  
>  > 
>  > Certainly there is no need to preculude that the client can learn
>  > certificates in an out-of-band fashion and that it could "guess"
>  > hashes for certification paths that a server might send based on
>  > certificates there were learned/configured out-of-band--but it is
>  > not the general case that this spec should address.
>  > 
>  I also imagine that we may have situations with clusters of hosts and/or
>  proxies with slight difference in configuration and where some 
> servers are
>  configured to send e.g. The whole path and another only the server
>  certificate, or where multiple paths are configured due to some CA
>  certificate renewals. My conclusion was that it would hurt more to 
> not have
>  the ability to include more than one hash if we need it than to 
> provide the
>  capability even though it's not used.
>  
>  
>  > Normally, the client should learn ("cache") the path from a previous
>  > full handshake with the server, and the client should probably
>  > replace the cached certification path entirely if the server
>  > does respond with a full path instead of the omission--rather
>  > than collecting pathes and starting to announce all of the
>  > hashes for all of the cached certification pathes that a specific
>  > server has ever used in the past.
>  > 
>  I was actually only thinking of caching, but in some environments it 
> might
>  actually be logical to do it in another way as you mention.
>  
>  > 
>  > Now what exactly are the characteristics for assuming that it already
>  > possesses a server certification path (this is related to the clients
>  > decision when to propose resuming a cached TLS session, but it's
>  > slightly different).
>  > 
>  > When client-side proxies are involved (aka HTTP CONNECT proxies),
>  > then the target IP-address visible at the network socket is pretty
>  > useless for distinguishing entries in the client-side cache.
>  > The client probably needs access to the hostname that was used
>  > to open the network connection (or the proxy CONNECT).
>  > 
>  > A TLS session resume always implies a fixed set of connection attributes
>  > (ciphersuite, server certification path).
>  > 
>  > How much should a cached server certification path imply?
>  > Any particular certification path (if agreed to by the server)
>  > will restrict the subset of TLS ciphersuites that can be used
>  > based on the keytype of the server certificate in that path,
>  > e.g.  DSA-cihpersuites require a server cert with a DSA-key,
>  > ECDSA-ciphersuites require a server cert with an ECDSA-key,
>  > RSA-ciphersuites require a server cert with an RSA-key,
>  > DHE-RSA ciphersuites require a server cert with an RSA-key
>  > which must have "digitalSignature" keyUsage asserted,
>  > DH-RSA ciphersuites require a server cert with a DH key, etc.
>  > 
>  I think it should imply exactly the same as if that server 
> certificate path
>  was sent over the wire.
>  
>  > 
>  > I think the document should provide guidance when to "update
>  > the cache" when the server sends a full certification path
>  > instead of the omission, and when the client should or could
>  > store the full certification path sent by the server as a
>  > valid alternative.
>  > 
>  Good suggestion.
>  
>  
>  > 
>  > -Martin
>  
>  
>

---

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

Hi Min,

A point raised I think would also be the possibility to provide hashes of
different kinds for the same certificate path, i.e. One SHA-1 and one SHA-2
hash.

To accommodate the possibility to send more than one hash is very easy.
I personally believe much more in the benefit of generality, than I fear the
danger of allowing multiple hash values.

On your second note it would appear at a first glance that sending the hash
twice is redundant. However I do think this redundancy make sense for the
state machine. The client benefits from knowing that the cashed information
is accepted through the server hello, to prepare for the altered handshake.
In the handshake, it make sense to include the data that will be processed
for the TLS finished message in order to leave that logic unchanged.

/Stefan

> Hi,Stefan

I also have the same consideration as Martin about actions of
> caching, updating and/or replacing the certificate path taken by the client.
> I think there may be not much necessary to collect/cache more than one
> certificates. In TLS Handshake process,server would treat the same client(or
> the same kind of clients) in the same way, which means that the server would
> like to send the same certificate or certificate path to the same client(or
> the
 same kind of clients) all most of the time. And I imagine this is the
> most general case in practice. 

If collect/cache more than one certificate
> paths, take certificate renewal into account, client will both cache the
> old(revocation) certificate path and the new certificate path(in fact, the old
> certificate path has turn to be redundant now), there will be a revocation
> mechanism of certificate hashes required,or the client would send the more and
> more hash values everytime when it do TLS handshake with the same server. This
> is just one exam
ple. That is, when client is designed to collect/cache more
> than one certificate paths, it may hold some useless/not much useful
> certificate paths, and send them to the sever during every TLS handshake.
> There should be some methods, which may be complex, to deal with it. So, why
> not collect/cache just one certificate path of the server?

In addition, here
> is another question, the server would send the hash of the certificate path
> contained in the extension of the server hello message, and then again in the
> server certificate message. The aim is to inform and be checked the client
> that the cached certificate path is valid, so once must be enough, do you
> think sending the same hashes twice from server to client is
> redundant?

regards,
Min Huang