Subject: Re: [TLS] Comments on the cached-info draft

From: Stefan Santesson <[email-masked]>
Date: Wed, 05 Dec 2012 09:59:37 +0100

Hi Joe,

I can't see the functionality being limited in any important way.
In fact, as mentioned below, I see that it actually opens up new
opportunities if you don't have to force the cached hash into existing
handshake messages.

Regarding caching of partial chain:
If the group feels that it would be compliant with section 7.4.2 of TLS
1.2, I guess that you could allow the server to send just the end
certificate if the client in a new CahcedInformationType has sent over a
matching hash of the chain (excluding the server cert) that the this
server usually sends together with the server certificate.

This is actually much easier to accommodate if we go for the cleaner
solution to just omit cached data in hs messages. This would have been
semantically horrific if we would mix the server certificate with a hash
of the cached chain in the same opaque blob.

/Stefan

On 11/28/12 6:19 AM, "Joseph Salowey (jsalowey)" <[email-masked]>
wrote:

>Hi Stefan,
>
>This new proposal of omitting the data sounds a bit simpler to me.   You
>say the new approach will limit the functionality in some way.  In what
>way is it limited?
>
>Do you think we could accommodate the case where the endpoint has
>intermediate CA certificates cached but not the end entity certificate?
>This would require parsing the certificate message, but the response
>could just omit the certs that were indicated in the cachedInfo.   The
>parsing of the cert message is a bit more complex, but it could satisfy
>some of the use cases discussed at the meeting.
>
>Thanks,
>
>Joe 
>
>
>
>On Nov 7, 2012, at 7:42 AM, Stefan Santesson wrote:
>
>> It was quite a while since I wrote the first version of this draft.
>> Now that I bring it up to my attention I found a problem that I think
>> should be fixed.
>> 
>> After a close examination I'm convinced that the current spec breaks
>>TLS.
>> 
>> 
>> The current approach is to exchange support for cached-info in client
>>and
>> server hellos.
>> This includes hashes for cached objects (clients) and confirmation of
>> cached objects (server).
>> 
>> In addition to this, this protocol allows the cached data in handshake
>> messages to be swapped with cached object hashes.
>> This is a violation of the syntax of these handshake messages.
>> 
>> Take the Certificate handshake message for example. The spec suggest
>>here
>> to replace the certificate_list vector to be replaced with a vector of
>> CachedObejct structured data.
>> This breaks the syntax of this handshake message. A strict processing of
>> the certificate_list vector will expect an ASN.1 encoded binary
>>containing
>> a sequence of certificates, not a vector of data objects according to
>>the
>> CachedObject structure.
>> 
>> My first thought was that we actually need a new handshake message.
>> However that is not helpful either.
>> The TLS spec require the Certificate handshake message to be sent in
>>case
>> the chosen cipher suite demands it, so it MUST be sent.
>> It can't be replaced by another handshake message.
>> 
>> My current belief is that we simply should omit the cached data, and
>>that
>> each cachedInfo type need to defined how to omit cached data.
>> 
>> In case of the certificate handshake message, the certificate list
>>should
>> be replaced with an empty sequence.
>> 
>> 
>> There is actually no need to send the hash of the cached data in the
>> handshake message. Not if the confirmation of the cached info is
>>exchanged
>> in the server hello. Sending the hash once more in the handshake message
>> is then redundant.
>> 
>> 
>> So I propose the following:
>> 
>> 1) Clients send hashes of cached objects in client hello.
>> 2) Server responds with one or zero hashes per cachedInfo type, that a)
>> matches a cached object sent by the client b) will be omitted by the
>> server in the corresponding handshake message.
>> 3) How information is omitted from the handshake message is defined per
>> cached info type. For the current defined 2 types this is:
>>  A) cached certificate cahins in Certificate: replace the sequence of
>> certificates with an empty sequence.
>>  B) certificate_authorities in Certificate Request: Send an empty list
>>of
>> DistinguishedName
>> 4) Clients will act as if the cached objects (confirmed in server hello)
>> were sent in the handshake messages.
>> 5) Everything else according to the current spec
>> 
>> 
>> The proposed approach will somewhat limit the functionality of the
>>current
>> spec, but it ads value in simplicity.
>> I can't imagine a valid use case that would not be covered by this
>>change,
>> but I might overlook something.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 5 Dec 2012 12:54:35 -0800

Stefan,

I agree that the current text violates TLS  1.2 by changing the message
specification in the handshake protocol.

Your proposal addresses those violations and simplifies the cached-info
exchange.
But it also adds ambiguity to certain use cases allowed by cached-info
draft.

The current text does not limit the number of certificate chain (or
trusted_cas) hashes that the client can include as part of client hello. In
some cases the client can include more than one certificate chain (or
trusted_cas) hashes.  Examples are scenarios where the client communicates
with same server with different SNIs  and scenarios where client connects to
the server using different cipher-suite preference or different signing/hash
algorithm preference.

One way to fix this would be to provide guidance on how the client and
servers can determine which cached objects should be included in hello
messages.  I guess it will require preprocessing of SNI and signature
algorithms extensions and also that of cipher-spec message at both the
client and the server. Clients would only include the cached objects that
comply with the above (for bandwidth optimization) and servers MUST only
include those that comply the SNI, algorithms and cipher-suite. Also the
servers MUST not include more than one cached object of the same type.

Thoughts?

-Piyush

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stefan Santesson
> Sent: Wednesday, December 05, 2012 1:00 AM
> To: Joseph Salowey (jsalowey)
> Cc: <[email-masked]>
> Subject: Re: [TLS] Comments on the cached-info draft
> 
> Hi Joe,
> 
opportunities
> if you don't have to force the cached hash into existing handshake
messages.
> If the group feels that it would be compliant with section 7.4.2 of TLS
1.2, I
> guess that you could allow the server to send just the end certificate if
the
> client in a new CahcedInformationType has sent over a matching hash of the
> chain (excluding the server cert) that the this server usually sends
together
> with the server certificate.
> 
solution
> to just omit cached data in hs messages. This would have been semantically
> horrific if we would mix the server certificate with a hash of the cached
chain
> in the same opaque blob.
> >>and  server hellos.
> >> In addition to this, this protocol allows the cached data in
> >> handshake messages to be swapped with cached object hashes.
> >>here  to replace the certificate_list vector to be replaced with a
> >>vector of  CachedObejct structured data.
> >> This breaks the syntax of this handshake message. A strict processing
> >>of  the certificate_list vector will expect an ASN.1 encoded binary
> >>containing  a sequence of certificates, not a vector of data objects
> >>according to the  CachedObject structure.
> >>
> >>case  the chosen cipher suite demands it, so it MUST be sent.
> >>that  each cachedInfo type need to defined how to omit cached data.
> >>
> >>should  be replaced with an empty sequence.
> >>
> >>
> >>exchanged  in the server hello. Sending the hash once more in the
> >>handshake message  is then redundant.
> >>
> >>
> >> 2) Server responds with one or zero hashes per cachedInfo type, that
> >>a)  matches a cached object sent by the client b) will be omitted by
> >>the  server in the corresponding handshake message.
> >> 3) How information is omitted from the handshake message is defined
> >>per  cached info type. For the current defined 2 types this is:
> >>  B) certificate_authorities in Certificate Request: Send an empty
> >>list of  DistinguishedName
> >> 4) Clients will act as if the cached objects (confirmed in server
> >>hello)  were sent in the handshake messages.
> >>current  spec, but it ads value in simplicity.
> >>change,  but I might overlook something.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>

---

From: [email-masked] (Martin Rex)
Date: Fri, 7 Dec 2012 08:15:29 +0100 (CET)

> of the cached chain in the same opaque blob.

Distinguishing a certificate from a hash should be extremely trivial.

The hash will have a fixed length (as defined by the protocol or
negotiated (were where we here?), and even the longest hash value
will be significantly shorter than the shortest valid X.509 certificate.

There would not have been any reason to use the caching extension
if the object that is to be omitted from the handshake was not
substantially larger than the hash value over that data.

-Martin

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 16 Dec 2012 01:00:41 +0000

Hi Piyush,

I think this is a good point.  In most cases the client is caching information from a previously successful handshake so it should not be too difficult for the client to select the appropriate hashes.    I think that the number of hashes of the same type that may be sent by the client or server would depend upon the type of cached info.  For example, if we allow caching of intermediate certificates then multiple hashes pertaining to one certificate chain may be sent.  It would not be permissible to send multiple hashes for the different chains since this would result in ambiguity as to which chain was used.    The document would have to define the appropriate behavior for each type.  

Does this capture the issue?  

Thanks,

Joe

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 16 Dec 2012 01:11:01 +0000

Are there any objections to:

a)  Stefan's new proposal to omit the cached data

b)  Accommodating a cached intermediate chain so only the end-entity  certificate needs to be sent.  

Thanks,

Joe

---

From: "Piyush Jain" <[email-masked]>
Date: Sun, 16 Dec 2012 11:25:51 -0800

Thanks Joe,

Yes - I think you have captured the issue. As you mentioned, providing
guidance on what to send and how to deal with each type of cached object
would address the issue.

Comment for Stefan - Your proposal is based on the assumption that passing
vector of cached objects in certificate message violates the protocol. At
first I also thought the same. However, on careful reading I think that
assumption is incorrect. RFC 5246 defines ASN.1Cert as opaque. So setting it
to a cert hash (or any other representation of the cert) would not be a
violation. 

-Piyush

> From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> Sent: Saturday, December 15, 2012 5:01 PM
> To: Piyush Jain
> Cc: Stefan Santesson; <[email-masked]>
> I think this is a good point.  In most cases the client is caching
information
> from a previously successful handshake so it should not be too difficult
for
> the client to select the appropriate hashes.    I think that the number of
> hashes of the same type that may be sent by the client or server would
> depend upon the type of cached info.  For example, if we allow caching of
> intermediate certificates then multiple hashes pertaining to one
certificate
> chain may be sent.  It would not be permissible to send multiple hashes
for
> the different chains since this would result in ambiguity as to which
chain was
> used.    The document would have to define the appropriate behavior for
> each type.
> 
> > I agree that the current text violates TLS  1.2 by changing the
> > message specification in the handshake protocol.
> >
> > Your proposal addresses those violations and simplifies the
> > cached-info exchange.
> > trusted_cas) hashes that the client can include as part of client
> > hello. In some cases the client can include more than one certificate
> > chain (or
> > trusted_cas) hashes.  Examples are scenarios where the client
> > communicates with same server with different SNIs  and scenarios where
> > client connects to the server using different cipher-suite preference
> > or different signing/hash algorithm preference.
> >
> > client and the server. Clients would only include the cached objects
> > that comply with the above (for bandwidth optimization) and servers
> > MUST only include those that comply the SNI, algorithms and
> > cipher-suite. Also the servers MUST not include more than one cached
> object of the same type.
> >
> > Thoughts?
> >
> > -Piyush
> >
> >
> >> client in a new CahcedInformationType has sent over a matching hash
> >> of the chain (excluding the server cert) that the this server usually
> >> sends
> > together
> >> to just omit cached data in hs messages. This would have been
> >> semantically horrific if we would mix the server certificate with a
> >> hash of the cached
> > chain
> >> in the same opaque blob.
> >>
> >> /Stefan
> >>
> >>
> >>> say the new approach will limit the functionality in some way.  In
> >>> what way is it limited?
> >>>
> >>> parsing of the cert message is a bit more complex, but it could
> >>> satisfy some of the use cases discussed at the meeting.
> >>>
> >>> Thanks,
> >>>
> >>> Joe
> >>>
> >>>
> >>>
> >>>> Now that I bring it up to my attention I found a problem that I
> >>>> think should be fixed.
> >>>>
> >>>> After a close examination I'm convinced that the current spec
> >>>> breaks TLS.
> >>>>
> >>>>
> >>>> The current approach is to exchange support for cached-info in
> >>>> client and  server hellos.
> >>>> This includes hashes for cached objects (clients) and confirmation
> >>>> of cached objects (server).
> >>>>
> >>>> Take the Certificate handshake message for example. The spec
> >>>> suggest here  to replace the certificate_list vector to be replaced
> >>>> with a vector of  CachedObejct structured data.
> >>>> This breaks the syntax of this handshake message. A strict
> >>>> processing of  the certificate_list vector will expect an ASN.1
> >>>> encoded binary containing  a sequence of certificates, not a vector
> >>>> of data objects according to the  CachedObject structure.
> >>>>
> >>>> The TLS spec require the Certificate handshake message to be sent
> >>>> in case  the chosen cipher suite demands it, so it MUST be sent.
> >>>> My current belief is that we simply should omit the cached data,
> >>>> and that  each cachedInfo type need to defined how to omit cached
> data.
> >>>>
> >>>> There is actually no need to send the hash of the cached data in
> >>>> the handshake message. Not if the confirmation of the cached info
> >>>> is exchanged  in the server hello. Sending the hash once more in
> >>>> the handshake message  is then redundant.
> >>>>
> >>>>
> >>>> a)  matches a cached object sent by the client b) will be omitted
> >>>> by the  server in the corresponding handshake message.
> >>>> A) cached certificate cahins in Certificate: replace the sequence
> >>>> of certificates with an empty sequence.

---

From: "Piyush Jain" <[email-masked]>
Date: Sun, 16 Dec 2012 11:42:08 -0800

Just a few comments
- As thought previously, the existing text does not violate TLS. TLS defines
ASN.1Cert as opaqe and certificate_list as list of ASN.1Cert. So you can
include a list of cached objects in certificate message.
- The benefit of the new proposal is that it avoids sending of information
that was already sent in server hello.
- The con is that it bundles the content of server certificate message in
server hello and requires some preprocessing on server and client in terms
of selecting which cached object to send as part of server hello.

So the question is :  What is the benefit of sending the cached object
extension as part of server hello? The server can avoid sending this
extension in server hello and just send the cached object(s) as part of the
certificate message.

-Piyush

> Joseph Salowey (jsalowey)
> Sent: Saturday, December 15, 2012 5:11 PM
> To: Stefan Santesson
> Cc: <[email-masked]>
> > If the group feels that it would be compliant with section 7.4.2 of
> > TLS 1.2, I guess that you could allow the server to send just the end
> > certificate if the client in a new CahcedInformationType has sent over
> > a matching hash of the chain (excluding the server cert) that the this
> > hash of the cached chain in the same opaque blob.
> >
> > /Stefan
> >
> >

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 17 Dec 2012 02:11:39 +0000

> include a list of cached objects in certificate message.

[Joe]  While this is true for the certificate chain, is it true for other types of data that may be cached as well?  would this work for distinguished names  for trusted_cas or for the multi-OCSP status response we have been discussing?  I'm a little concerned that it might not work in all cases.  Since the cached info type has to be explicitly defined it would be sufficient that it works with the types that are likely to be useful to cache.  

> of selecting which cached object to send as part of server hello.

[Joe]  I'm leaning towards it being simpler to omit the hash if possible.  

> extension in server hello and just send the cached object(s) as part of the

[Joe] I'm not sure I follow you here.  The server needs to know what the client has cached so it can tell if it needs to send the hash or the actual data.

---

From: "Piyush Jain" <[email-masked]>
Date: Sun, 16 Dec 2012 21:10:49 -0800

Sorry for being unclear on the last part. Let me try again.

The current text requires that the server returns the cached objects as an
extension in server hello. The reason cited is that the server tells the
client which cached objects are understood by the server.
These objects could be one of certificate chain, CA DN and possibly OCSP
multi status.

TLS requires that CA DN be sent in Client Certificate request message,
server certificate chain be sent in Certificate message and OCSP status be
sent in Certificate status message.

Stefan's proposal is that since all the cached objects are sent back in
Server hello, there is no need to send cert chain cache objects in Server
Certificate message or cached OCSP in Certificate Status message.

I think that we can do away with the requirement of returning any cached
object as server hello extension.
Here are the steps
-The client sends the list of cache objects in client hello.
-Server DOES NOT acknowledge any cached objects via hello extension
- Server sends cached cert chain as part of certificate_list in Server
Certificate message ( allowed  - ASN.1Cert is defined as opaque in TLS)
-Server Sends cached multi ocsp responses as part of Certificate status
message ( allowed - OCSResponse is defined as opaque in multi-status draft)
- Server sends cached ca dns as part of client certificate request message.
(allowed - distinguished name is defined as opaque in TLS)

The point is that there is no benefit of explicitly telling the client what
cached objects server understands as part of server hello message.
Server can use the cached object specified by the client on as needed basis.
This way we also avoid the situation where the cached objects are sent to
the client twice.

This way you do not need to bundle all the information in server hello and
pass the data only when it is required by the relevant TLS message and
obviates the need for client and server to do any preprocessing to figure
out which cached objects are sent during the hello message.

Can you think of any issues with not sending the cached objects in server
hello extension?

Thanks
-Piyush

> Sent: Sunday, December 16, 2012 6:12 PM
> To: Piyush Jain
> > - As thought previously, the existing text does not violate TLS. TLS
> > defines ASN.1Cert as opaqe and certificate_list as list of ASN.1Cert.
> > So you can include a list of cached objects in certificate message.
> 
> [Joe]  While this is true for the certificate chain, is it true for other
types of
> data that may be cached as well?  would this work for distinguished names
> for trusted_cas or for the multi-OCSP status response we have been
> discussing?  I'm a little concerned that it might not work in all cases.
Since the
> cached info type has to be explicitly defined it would be sufficient that
it
> works with the types that are likely to be useful to cache.
> 
> > - The benefit of the new proposal is that it avoids sending of
> > information that was already sent in server hello.
> > - The con is that it bundles the content of server certificate message
> > in server hello and requires some preprocessing on server and client
> > in terms of selecting which cached object to send as part of server
hello.
> > extension in server hello and just send the cached object(s) as part
> > of the certificate message.
> >
> 
> [Joe] I'm not sure I follow you here.  The server needs to know what the
> client has cached so it can tell if it needs to send the hash or the
actual data.
> >>> opportunities if you don't have to force the cached hash into
> >>> existing handshake messages.
> >>>
> >>>
> >>> TLS 1.2, I guess that you could allow the server to send just the
> >>> end certificate if the client in a new CahcedInformationType has
> >>> sent over a matching hash of the chain (excluding the server cert)
> >>> that the this server usually sends together with the server
certificate.
> >>> solution to just omit cached data in hs messages. This would have
> >>> been semantically horrific if we would mix the server certificate
> >>> with a hash of the cached chain in the same opaque blob.
> >>>
> >>> /Stefan
> >>>
> >>>
> >>>>> 3) How information is omitted from the handshake message is
> >>>>> defined per cached info type. For the current defined 2 types this

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 18 Dec 2012 06:39:48 +0000

Thanks, this helps, some questions and comments below:
On Dec 16, 2012, at 9:10 PM, Piyush Jain <[email-masked]> wrote:

> cached objects server understands as part of server hello message
>   
[Joe]  The client would still need to do some processing to determine which hash to send in the client hello. 

> Can you think of any issues with not sending the cached objects in server

[Joe]   Its not clear to me that the server needs to send the hashes of the cached objects at all.  The server does not need to tell the client the value of the hash of the data is since the client sent it in the client hello.  It just needs to be able to unambiguously determine if the server is using that cached data or providing a different set of data.    If we go with just omitting the data there may be some ambiguity between an empty message representing cached data and an empty message representing something else.   To remove this ambiguity the server could just send an enumeration of the cached object types it accepted in the hello extension  (the semantics for the server hello extension in the current draft may be different).

---

From: [email-masked] (Martin Rex)
Date: Tue, 18 Dec 2012 08:20:38 +0100 (CET)

Joseph Salowey (jsalowey) wrote:
> [Joe]   Its not clear to me that the server needs to send the hashes
> of the cached objects at all.  The server does not need to tell the
> client the value of the hash of the data is since the client sent it
> in the client hello.  It just needs to be able to unambiguously
> determine if the server is using that cached data or providing a
> different set of data.    If we go with just omitting the data there
> may be some ambiguity between an empty message representing cached
> data and an empty message representing something else.   To remove this
> ambiguity the server could just send an enumeration of the cached
> object types it accepted in the hello extension  (the semantics for
> the server hello extension in the current draft may be different).     

The certificate_authorities list in the CertificateRequest
handshake message is one such element, where omitting already
has a valid protocol meaning (at least in TLSv1.1+), and this
field also allows "small" values, potentially of the size of
a hash value, so disambituation appears to be necessary.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 18 Dec 2012 07:53:19 -0800

> [Joe]  The client would still need to do some processing to determine
which
> hash to send in the client hello.
> 
[Piyush] It'll be nice for client to do it because if will reduce the
message size. But this method will work even if client sends all the cached
objects it has.
The extension is just a means to communicate what objects client possesses.
> 
> > Can you think of any issues with not sending the cached objects in
> > server hello extension?
> >
> 
> [Joe]   Its not clear to me that the server needs to send the hashes of
the
> cached objects at all.  The server does not need to tell the client the
value of
> the hash of the data is since the client sent it in the client hello.  
[Piyush] Agreed

> It just needs to be able to unambiguously determine if the server is using
that cached data
> or providing a different set of data.    If we go with just omitting the
data
> there may be some ambiguity between an empty message representing
> cached data and an empty message representing something else.   
[Piyush]  Good point. Martin gave a specific example of this - CA
distinguished names.

> remove this ambiguity the server could just send an enumeration of the
> cached object types it accepted in the hello extension  (the semantics for
the
> server hello extension in the current draft may be different).
>
[Piyush] Absolutely.  And these enumerations (one per message) could be a
combination of complete objects and cached objects where cached objects are
picked from the list that the client sent in client hello.