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

From: Stefan Santesson <[email-masked]>
Date: Mon, 09 Mar 2009 17:20:39 +0100

Hi Min,

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.

On 3/9/09 12:00 PM, "Min Huang" <[email-masked]> wrote:

> Hi, Stefen
>  
> I have read the draft-santesson-tls-certcache-00.txt,and I have some
> questions.
>  
> 1).In the section 2, ³The certificate_hash value MUST include at least one
> hash value calculated over an expected certificate_list element of a server
> side Certificate ²
>  
> Why do you say ³at least one hash value²? Is there any possibility that can be
> other hash value? My understanding is that the hash value is the hash of the
> whole certificate_list of a server side Certificate message. Did I miss
> something here?
>  
> 2).In the section 4,
> ³Servers that receive an extended client hello containing a "cached_certs"
> extension, MAY indicate that they are willing to accept omitting certificate
> data in the Server Certificate message by including an extension of type
> "cached_certs" in the (extended) server hello, which SHALL contain a hash
> received in the cached_certs extension from the client, which is a complete
> hash calculated over all omitted certificates.²
> 
> Does the two ³which² mean the same thing? I think they are not always the
> same, in some cases they are different.Then the hash value will be which one?
>  
> 3).There are two editorial errors:
> a.Section 3 is missing .
> b. struct {
>      opaque certificate_hash; <1..2^8-1>
>   } CachedCerts;
> ²;² after ³certificate_hash² should be put after <1..2^8-1>.
>  
> regards,
> Min Huang
>  
>  
>> >Date: Thu, 05 Mar 2009 00:47:44 +0100
>> >From: Stefan Santesson <[email-masked] <mailto:[email-masked]> >
>> >Subject: [TLS] New "Fast-Track" draft posted
>> >To: TLS wg <[email-masked] <mailto:[email-masked]> >
>> >Message-ID: <[email-masked]
>> <mailto:[email-masked]> >
>> >Content-Type: text/plain; charset="iso-8859-1"
>  
>> >As a result of the discussions we had around last IETF I have now posted a
>> >new ?Fast Track? inspired draft.
>  
>> >The name of this draft is  draft-santesson-tls-certcache-00
>> >It will be available in a few days from the I-D repository. Until then it
>> >can be obtained from the staging site at:
>> >http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.txt
>> 
<http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.txt>>
> 
>  
>> >I have chosen to do a completely new draft instead of updating the old
>> >fast-track document as I have used a very simplified approach as starting
>> >point.
>> >My document is limited to one new TLS extension with the sole purpose of
>> >including a hash of a cached cert path to allow this cert path to be omitted
>> >from the server Certificate message.
>  
>> >I submitted this draft to inject some energy into the discussion again but
>> >I?m not locked on the approach if there are good reasons to expand it.
>> >Please read and provide comments.
>  
>> >I would like to request a small time slot on the TLS meeting agenda in San
>> >Francisco to discuss this if possible.
>> >
>> >
>> >Stefan Santesson
>> >AAA-sec.com
>

---

From: Min Huang <[email-masked]>
Date: Mon, 09 Mar 2009 19:00:58 +0800

Hi, Stefen

1).In the section 2, "The certificate_hash value MUST include at least one
hash value calculated over an expected certificate_list element of a server
side Certificate "
 
Why do you say "at least one hash value"? Is there any possibility that can
be other hash value? My understanding is that the hash value is the hash of
the whole certificate_list of a server side Certificate message. Did I miss
something here?
 
2).In the section 4,
"Servers that receive an extended client hello containing a "cached_certs"
extension, MAY indicate that they are willing to accept omitting certificate
data in the Server Certificate message by including an extension of type
"cached_certs" in the (extended) server hello, which SHALL contain a hash
received in the cached_certs extension from the client, which is a complete
hash calculated over all omitted certificates."

Does the two "which" mean the same thing? I think they are not always the
same, in some cases they are different.Then the hash value will be which
one? 
 
3).There are two editorial errors:
a.Section 3 is missing .
b. struct {
     opaque certificate_hash; <1..2^8-1>
  } CachedCerts;
";" after "certificate_hash" should be put after <1..2^8-1>.
 
regards,
Min Huang

>From: Stefan Santesson < <mailto:[email-masked]> [email-masked]>
>To: TLS wg < <mailto:[email-masked]> [email-masked]>
>Message-ID: < <mailto:[email-masked]>
[email-masked]>

>can be obtained from the staging site at:
<http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.tx
t>
http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.txt

---

From: Min Huang <[email-masked]>
Date: Tue, 10 Mar 2009 20:42:46 +0800

Hi，Stefan
 
Thank you for your explanation. 
 
According to your explanation:
 
“the client may include a number of hashes, matching different sets of
server 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 above statement or some similar statement should be added to the
text. Moreover, some error disposals, such as if there is no matched hash
value in client hello message, what action server would take. IMO, all of
those will make the text clearer.
 
Just my two cents…

regards,
Min

  _____  

发件人: Stefan Santesson [mailto:[email-masked]] 
发送时间: 2009年3月10日 0:21
收件人: Min Huang
抄送: [email-masked]
主题: Re: New "Fast-Track" draft posted

Hi Min,

Hi, Stefen

1).In the section 2, “The certificate_hash value MUST include at least one
hash value calculated over an expected certificate_list element of a server
side Certificate ”
 
Why do you say “at least one hash value”? Is there any possibility that
can be other hash value? My understanding is that the hash value is the hash
of the whole certificate_list of a server side Certificate message. Did I
miss something here?
 
2).In the section 4,
“Servers that receive an extended client hello containing a "cached_certs"
extension, MAY indicate that they are willing to accept omitting certificate
data in the Server Certificate message by including an extension of type
"cached_certs" in the (extended) server hello, which SHALL contain a hash
received in the cached_certs extension from the client, which is a complete
hash calculated over all omitted certificates.”

Does the two “which” mean the same thing? I think they are not always the
same, in some cases they are different.Then the hash value will be which
one? 
 
3).There are two editorial errors:
a.Section 3 is missing .
b. struct {
     opaque certificate_hash; <1..2^8-1>
  } CachedCerts;
”;” after “certificate_hash” should be put after <1..2^8-1>.
 
regards,
Min Huang

 
>http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.tx
t <http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.
txt>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 10 Mar 2009 15:15:26 +0100

Thanks Min,

I agree on both your comments. I will add text on these matters in the next
version of the document.
As with the issue what the server would do if there is no match. Then the
server would proceed with a normal handshake. But it does not hurt to say
so.

/Stefan

On 3/10/09 1:42 PM, "Min Huang" <[email-masked]> wrote:

> “the client may include a number of hashes, matching different sets of server
> 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 above statement or some similar statement should be added to the text.
> Moreover, some error disposals, such as if there is no matched hash value in
> client hello message, what action server would take. IMO, all of those will
> make the text clearer.
>  
> Just my two cents…
>  
> regards,
> Min
> 
> 
> because I was not sure that there are no situation where that could be useful.
> 
> 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.
> 
> 
> 
>> Why do you say “at least  one hash value”? Is there any possibility that can
>>> t

---

From: Martin Rex <[email-masked]>
Date: Tue, 10 Mar 2009 17:54:04 +0100 (MET)

> 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.

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.

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.

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 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.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 12 Mar 2009 19:16:25 +0100

Martin,

Thanks for your extensive feedback. Comments in-line.

/Stefan

> collect/cache more than one certification path as "valid" in the first place.

Agree, I think it is reasonable to make such clarification.

> 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.

> 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.

> 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.

> store the full certification path sent by the server as a
Good suggestion.