Subject: [TLS] TLS Fast-Track resurrected?

From: Stefan Santesson <[email-masked]>
Date: Tue, 2 Dec 2008 19:27:23 +0000

At the last IETF I brought up the question whether we should bring the old TLS Fast-Track work back to life.
The general opinion was positive.

In short, my proposal is to generate a new draft inspired by the old TLS Fast Track draft (http://tools.ietf.org/html/draft-shacham-tls-fast-track-00)
The new proposal would change the old proposal in the following way:

* Only use extensions. Not defining new Client and Server Hello messages
* Keep general design of the fast-track extension but add hash algorithm agility.
* Reduce determining parameters to be hashed.

I'm open to suggestions on how to, if at all, reduce the old determining parameters from Fast Track section 4.1, but I would suggest to just hash the server certificate and then do a normal TLS session setup except from not sending over the TLS server certificate if the client has correctly identified the server certificate in the client hello extension.

We may lose some degree of optimization, but would gain in simplicity.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

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

---

From: <[email-masked]>
Date: Wed, 3 Dec 2008 12:15:13 +0200

If we do this, I'd suggest also including the "certificate_authorities" 
list from CertificateRequest. If the trust anchor list is large (as
it often is in e.g. typical Windows setups), that's easily over 3 KB
(similar size, or even larger, than the server certificate chain). 
And it's often sent even if the client won't actually use TLS
client authentication.

A data point: I took a dump of TLS-protected handshake done by an
unnamed Microsoft product (no session resumption, no client
authentication). The TLS handshake messages were 7391 bytes. With 
a simple "send SHA-256 hash of server certificate and
certificate_authorities list in ClientHello extension" design, 
that would have been about 415 bytes, saving almost 7 KB (over 90%).

(If this was just e.g. 25%, it IMHO wouldn't be worth doing -- it
wouldn't be a good engineering tradeoff between added complexity
and saved bytes. But if we save over 90%, that sounds much better...)

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Stefan Santesson
> Sent: 02 December, 2008 21:27
> To: [email-masked]
> Subject: [TLS] TLS Fast-Track resurrected?
> 
> At the last IETF I brought up the question whether we should 
> bring the old TLS Fast-Track work back to life.
> In short, my proposal is to generate a new draft inspired by 
> the old TLS Fast Track draft 
> (http://tools.ietf.org/html/draft-shacham-tls-fast-track-00)
> I'm open to suggestions on how to, if at all, reduce the old 
> determining parameters from Fast Track section 4.1, but I 
> would suggest to just hash the server certificate and then do 
> a normal TLS session setup except from not sending over the 
> TLS server certificate if the client has correctly identified 
> the server certificate in the client hello extension.
>

---

From: Martin Rex <[email-masked]>
Date: Wed, 3 Dec 2008 16:28:09 +0100 (MET)

Stefan Santesson wrote:
> 
> At the last IETF I brought up the question whether we should bring
> the old TLS Fast-Track work back to life.
> In short, my proposal is to generate a new draft inspired by the old TLS
> Fast Track draft (http://tools.ietf.org/html/draft-shacham-tls-fast-track-00)
> I'm open to suggestions on how to, if at all, reduce the old determining
> parameters from Fast Track section 4.1, but I would suggest to just hash
> the server certificate and then do a normal TLS session setup except
> from not sending over the TLS server certificate if the client has
> correctly identified the server certificate in the client hello extension.
> 

I briefly read through the document and to me it appears to be
a complex and extremly ugly mutilation and contortion of the TLS protocol.

If at all, I would appreciate an approach that is orthogonal to
other TLS extensions and with minimal impact on the regular TLS
handshake.

How about an approach with one "simple" TLS (client) hello extension
where the client can provide a _list_ of parameters it has cached
along with a hash over the value, and where the server can decide
for each entry/hash in the list whether to send the information or
whether to send a short replacement tag that indicates to the
client that he should use his cached information.

Two possibilities:
      a list of   integer-tag plus hash-value
  or  a list of   bitfield    plus hash-value

the integer tags (or the bits of the bitfield) should be standardized/
registered so that the cached information is extensible, can also be
used to signal cached values from other TLS extensions and the server
can ignore cache hints that it doesn't understand.

If a bitfield is used, it would be possible to create a single
hash over a concatenation of several independent cached values,
however the number space is much smaller and would have to be
managed more carefully.  Alternatively, one could assign
integer-tags to indicate that the hash is over a concatenation
of a specific set of cached values.

The original document claims that the number of round-trips could
be reduced through the the use of the modified FastTrack-Handshake
-- but I don't think this is generally true.

In the normal case, the client that opens the communication channel
and starts the TLS handshake will also be the one who sends the
first application data.  Technically, the client can piggy-back that
first application data onto the Clients Finished handshake message
as long as the client trusts in the encryption of the established
TLS communication channel (to me that is similar to the GSS-API v2
PROT_READY approach).  I don't see a significant technical reason
why the client should have to wait for the servers Finished
handshake message -- other than the client might start to consume
a significant network bandwidth without knowing whether the
TLS handshake was actually completed successfully.

Personally, I wouldn't mind if the client only did start sending
application data before receiving the servers ChangeCipherSpec&Finished
message in case that the server has agreed to perform an optimized
fast track handshake (by omitting those parts of information from
the regular TLS handshake where the client-signalled hash matches
the information that the server would normally send in the handshake.

-Martin

---

From: Mike <[email-masked]>
Date: Wed, 03 Dec 2008 14:30:38 -0800

This is an interesting idea, but quite complex for what it
appears to want to do.  Instead of trying to come up with
a collection of fast-track parameters and hashing them all
together, keeping them separate would be simpler and more
flexible.

For example, one of the major goals is for the server to
not send its Certificate message.  To accommodate this
optimization, there could be a cached_server_certificate
extension which would contain a server-defined value that
represents its certificate (most likely a hash).

The first connection a client makes would contain an empty
cached_server_certificate extension.  If the server knows
about the extension, it replies with the same extension,
but which has been filled with a value that it associates
with its certificate chain.  The value can be a hash of the
end entity certificate or of the whole chain, or even just
a sequential number it increases each time its certificate
is replaced.  Leaving the format of the value unspecified
provides hash agility since a server can use any hash it
wants.  For this initial handshake, the server must also
send its Certificate message, since the client does not
yet have a copy of it.

When the client reconnects, it provides the server's value
from a previous handshake in its cached_server_certificate
extension.  If the server can match the value to one of
its certificate chains, then it replies with the same value
in its extension and does not send the Certificate message
during the handshake.  If the value is unrecognized, the
server acts as if the client's extension was empty.

I didn't think too much about the other parameters that
might also benefit from fast-tracking, but they can probably
be similarly defined.  But adding just this simple extension
will probably save the majority of the bandwidth (since few
connections use client authentication).

Mike

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Dec 2008 16:53:02 -0600

draft-shacham-tls-fast-track-00 claims stateful session resumption as a
motivator for that work.  But RFC4507 fixes that problem.

Are there other motivations for TLS Fast-Track given RFC4507?

Let's put it another way.  If a client and server support both, RFC4507
and Fast-Track, then: a) a client that chooses RFC4507 will not have an
opportunity to use Fast-Track until the session ticket expires, b)
RFC4507 resumption should be lighter-weight[*] than Fast-Track, so why
would a client prefer to use Fast-Track instead of RFC4507?

[*] Servers will typically have to perform a symmetric decryption
    operation for fast stateless session resumption (RFC4507); clients
    and servers also derive new session keys, otherwise that's it.

    Whereas Fast-Track always has a ClientKeyExchange, so there's always
    some public key operation in Fast-Track unless PSK is being used.

As I see it RFC4507 should terminate all interest in Fast-Track.  No?

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 4 Dec 2008 01:30:16 +0200

Not really. Fast-Track is for establishing TLS when the old session  
ticket has already expired (maybe it's your first connection for the  
day).  It makes the first connection (the one that can't benefit from  
session resumption, stateless or otherwise) take less bytes.

That said, I'm not convinced it's all that useful without lots of  
assumptions about low bandwidth and charge-by-bytes. Most of us can  
afford to send a certificate chain every few hours.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Dec 2008 17:41:05 -0600

> session resumption, stateless or otherwise) take less bytes.

I got that, but if you're doing session resumption w/o server-side state
then the cost of one regular TLS handshake will be amortized over many
resumptions, so what's the point of Fast-Track?

> afford to send a certificate chain every few hours.

Exactly!

Nico

---

From: Mike <[email-masked]>
Date: Wed, 03 Dec 2008 15:59:55 -0800

With the economy in a tailspin and people coming to the realization
that they can't afford to live beyond their means, we may actually see
some people cancel their DSL/Cable Internet and return to (gasp!) 56k
modems.  They will want server-side session caches and fast-track cert
chain caching to minimize delays.

Also looking at it from the server's perspective, if fast-track cert
chain caching saves a few kB of bandwidth per client per day, you need
to multiply that by the number of clients to see the true benefit.

Mike

Yoav Nir wrote:
> I'm not convinced it's all that useful without lots of

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Dec 2008 18:21:51 -0600

> chain caching to minimize delays.

Economic crises don't work that way.  The real price of broadband is not
likely to go up by so much that we'll end up using 56k, nor is the price
of 56k lower now, and in any case, if you do session resumption w/o
server-side state then you're amortizing one full handshake over many
resumptions, so Fast-Track is pointless.

> to multiply that by the number of clients to see the true benefit.

That makes more sense.

Nico

---

From: Mike <[email-masked]>
Date: Wed, 03 Dec 2008 17:21:43 -0800

> resumptions, so Fast-Track is pointless.

It's not that I think broadband prices will go up, but that many people
who currently pay for it will realize that they can't really afford it.
It's been a long time since I priced dial-up, but a quick google search
indicates you can save 50% or more over broadband by using dial-up.  A
lot of people are going to have to make the difficult choice to go back
to a modem.

The reason for fast-track is to make that one full handshake faster, by
eliminating the transfer of the server's certificate chain (at least).
This is also why a modem user would not enable client-side caching; it
requires an extra payload to be transferred on every resumption.

Mike

---

From: <[email-masked]>
Date: Thu, 4 Dec 2008 15:05:53 +0200

> As I see it RFC4507 should terminate all interest in Fast-Track. No?

They would operate on quite different time scales.

TLS session resumption (with or without server-side state) requires
storing confidential information (the master secret), and a TLS client
probably won't use persistent storage for it.  Also, RFC 5246 suggests
an upper limit of 24 hours for session cache entries.

The server certificate (and certificate_authorities list), on the
other hand, are not secret, and could be stored (on disk) for months
or years.

But yes, you do have a point in that an optimization that gets used 
only once a day (or once every TLS client restart) isn't that great 
optimization from the client's point of view (server's point of view 
may be different).

Best regards,
Pasi

---

From: "Mohamad Badra" <[email-masked]>
Date: Thu, 4 Dec 2008 15:04:53 +0100 (CET)

> other hand, are not secret, and could be stored (on disk) for months

It is true the master_secret should be protected when storing it.
Trustworthy Certificate Authorities cannot easily be falsified. However,
attackers that are able to retrive the master_secret may also be able to
insert a falsified CA in the list of trustworthy CA, in which the client
will accept any certificate issued by the falsified CA.

So I think we may have the same problem when we store the CA list on the
disk.

Best regards,
-- 
Mohamad Badra
CNRS - LIMOS Laboratory

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 4 Dec 2008 14:40:54 +0000

Nico,

For some usage of TLS the cost of sending a certificate path is negligible. For others it's not.
The problem may be multiplied by transmission errors. For some usages in EAP TLS, this optimization would significantly improve performance.

Stefan Santesson
Senior Program Manager

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Nicolas Williams
> Sent: den 4 december 2008 00:41
> To: Yoav Nir
> Cc: [email-masked]
> Subject: Re: [TLS] TLS Fast-Track resurrected?
>

---

From: "Mohamad Badra" <[email-masked]>
Date: Thu, 4 Dec 2008 17:02:35 +0100 (CET)

Hi Stefan,

> The problem may be multiplied by transmission errors. For some usages in
> EAP TLS, this optimization would significantly improve performance.

I think we should define a "specific" renegotiation if we really want to
specify this major modification of TLS. EAP-TLS relies on the
renegotiation to enable privacy, but this increases dramatically the
performance and IMO there is no need to establish a full key exchange
during the second TLS session when both the client and the server agree on
using the so-called Fast-Track.

BWT, I still don't see the big advantage of Fast-Track over the OCSP
extension. OCSP includes several advantages (e.g., the client will be able
to get the current certificate status of the server during the TLS
Handshake, which may not be possible with Fast-Track). If more
optimisation is needed, this same extension could be redifined (another
extension) so the client can send also (instead of the certificate_chain)
the Distinguished Name of the CA of its certificate_list; so the server
can determine whatever "the to be sent" client certificate is acceptable
or not. And if then the certificate request will be sent empty, and
otherwise, the server stops the session.

The draft says: "The clients rarely connect to numerous TLS servers".
Anyone have any data to back that claim? And if this is correct, why don't
then rely on RFC5077?

Best regards,

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Dec 2008 18:23:08 +0100 (MET)

> So I think we may have the same problem when we store the CA list on the

Which CA list are you referring to?

The list of certification_authorities from the CertificateRequest handshake
message that FastTrack would want to cache is not used for verification
of certificate chains by the client, it is only used for selecting
an appropriate client certificate.

If you're referring to the (persistence of the) clients credentials
which IMHO includes the clients trust anchors (usually represented
by (CA/RootCA and selected EE) certs, then your observation is
correct.  If that is not properly protected, the client may loose
his entire security.

Btw. this also applies to the server.  If you operate an SSL Server
that accepts clients authenticating with SSL client certificates,
then the Servers private key is not necessarily the most critical
component.  Depending on how client (certs) are mapped to user
accounts, the SSL Servers list of trust anchors might be much
more critical.  However, todays PKI software is usually much
better at protecting/hiding private keys than it is at
protecting/hiding the list of trust anchors...

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Dec 2008 12:08:26 -0600

On Thu, Dec 04, 2008 at 02:40:54PM +0000, Stefan Santesson wrote:
> For some usage of TLS the cost of sending a certificate path is
> negligible. For others it's not.  The problem may be multiplied by
> transmission errors. For some usages in EAP TLS, this optimization
> would significantly improve performance.

OK, Fast-Track for EAP-TLS makes more sense, thanks.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Mohamad Badra" <[email-masked]>
Date: Thu, 4 Dec 2008 19:34:02 +0100 (CET)

> correct.  If that is not properly protected, the client may loose

I refer to the second case.

Best regards,

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Dec 2008 12:14:16 -0600

> using the so-called Fast-Track.

The I-D I looked at yesterday always requires a full key exchange in any
Fast-Track case.

If you want to avoid key exchanges then use RFC4507.

> extension. OCSP includes several advantages (e.g., the client will be able

Fast-Track is about cutting down bandwidth due to sending large cert
chains.  What does OCSP have to do with that?

> Anyone have any data to back that claim? And if this is correct, why don't

That was my question.  The answer seems to be: a) Fast-Track helps
servers, b) Fast-Track helps EAP-TLS.  That's good enough for me, though
I still think that RFC4507 should suffice most of the time.

Nico

---

From: "Mohamad Badra" <[email-masked]>
Date: Thu, 4 Dec 2008 19:48:12 +0100 (CET)

> chains.  What does OCSP have to do with that?

You are right, there is no relationship, my mistake:)

Best regards,

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Dec 2008 22:51:01 +0100 (MET)

Mohamad Badra wrote:
> optimisation is needed, this same extension could be redefined (another

If the Fast-Track design was simplified in the way I suggested, it
would be trivial to combine Fast-Track with both, the OCSP extension and
RFC4507.

If there is value in caching fairly static information from the
full SSL/TLS handshake on the client side, then there is even more
value if it is done in a fashion orthogonal to the TLS handshake
protocol so that it can be reused for static data of almost every
conceivable TLS extension.  A much simpler approach through mostly
a simple TLS (client) hello extension would also have the benefit
that it reduces the necessary code changes and resulting complexity
to the protocol engine of an existing implementation.

I really wouldn't change anything about the protocol and the
handshake message -- only define the representation of a "replacement tag"
to send in place of the information that the client already has,
and such posession has been confirmed to the server by the inclusion
of a matching (tagged) hash for this piece of information in a simple
TLS "Fast-Track" hello extension containing a list of tag&hash-value pairs.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Dec 2008 16:07:30 -0600

> TLS "Fast-Track" hello extension containing a list of tag&hash-value pairs.

+1

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 4 Dec 2008 14:38:25 -0800

I have seen instances where certificate_authorities have been
problematic for certain clients in EAP-TLS.  It would be good to have a
way to avoid sending all this data as well.  Making the solution a bit
more generic would be good.  

Cheers,

Joe

> Behalf Of [email-masked]
> Sent: Wednesday, December 03, 2008 2:15 AM
> To: [email-masked]; [email-masked]
> list from CertificateRequest. If the trust anchor list is 
> large (as it often is in e.g. typical Windows setups), that's 
> easily over 3 KB (similar size, or even larger, than the 
> server certificate chain). 
> A data point: I took a dump of TLS-protected handshake done 
> by an unnamed Microsoft product (no session resumption, no 
> client authentication). The TLS handshake messages were 7391 
> bytes. With a simple "send SHA-256 hash of server certificate 
> and certificate_authorities list in ClientHello extension" 
> design, that would have been about 415 bytes, saving almost 7 
> KB (over 90%).
> 
> (If this was just e.g. 25%, it IMHO wouldn't be worth doing 
> -- it wouldn't be a good engineering tradeoff between added 
> complexity and saved bytes. But if we save over 90%, that 
> sounds much better...)
> 
> Best regards,
> Pasi
> 
> > At the last IETF I brought up the question whether we 
> should bring the 
> > old TLS Fast-Track work back to life.
> > In short, my proposal is to generate a new draft inspired 
> by the old 
> > TLS Fast Track draft
> > determining parameters from Fast Track section 4.1, but I would 
> > suggest to just hash the server certificate and then do a 
> normal TLS 
> > session setup except from not sending over the TLS server 
> certificate 
> > if the client has correctly identified the server 
> certificate in the 
> > client hello extension.
> >

---

From: Martin Rex <[email-masked]>
Date: Fri, 5 Dec 2008 00:50:46 +0100 (MET)

> more generic would be good.  

What level of "avoiding" are you referring to?

Fast track can not make you avoid the original full SSL handshake entirely,
it can only help you to fast-track repeated "full SSL handshakes".

The ratio of the original full SSL handshakes vs fast-tracked full SSL
handshakes depends on (a) how often the servers fast-tracked information
is (administratively) changed and how long the client is willing and
capable of caching/persisting a servers fast-trackable information.

-Martin

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 4 Dec 2008 21:54:28 -0800

> From: Martin Rex [mailto:[email-masked]] 
> Sent: Thursday, December 04, 2008 3:51 PM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]; [email-masked]; [email-masked]
> > problematic for certain clients in EAP-TLS.  It would be 
> good to have 
> > a way to avoid sending all this data as well.  Making the 
> solution a 
> > bit more generic would be good.
> 
> Fast track can not make you avoid the original full SSL 
> handshake entirely, it can only help you to fast-track 
> repeated "full SSL handshakes".
> 
> The ratio of the original full SSL handshakes vs fast-tracked 
> full SSL handshakes depends on (a) how often the servers 
> fast-tracked information is (administratively) changed and 
> how long the client is willing and capable of 
> caching/persisting a servers fast-trackable information.
>
[Joe] The less the better.  If the client only had to deal with this
rarely (weekly or monthly) that would be an improvement.  In many cases
the clients have no use for this information even if they are going to
do client authentication, so it might be better to have the client
signal whether it is interested in this information and include hash if
it is interested.

---

From: "tom.petch" <[email-masked]>
Date: Fri, 5 Dec 2008 10:42:41 +0100

----- Original Message -----
From: "Stefan Santesson" <[email-masked]>
To: "Nicolas Williams" <[email-masked]>; "Yoav Nir"
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 04, 2008 3:40 PM
Subject: Re: [TLS] TLS Fast-Track resurrected?

> For some usage of TLS the cost of sending a certificate path is negligible.
For others it's not.

My own experience of low bandwidth is that it is the CRL that kills it.

I have a growing list of websites I would rather have nothing to do with as
access to them leads to a blank screen (for what feels like several minutes) and
a Megabyte or two of data download.  Looking under the covers usually reveals a
click counter script with https: and a Megabyte or so of CRL in temporary
storage.  The really annoying ones download the CRL several times in quick
succession.

Tom Petch

> The problem may be multiplied by transmission errors. For some usages in EAP
TLS, this optimization would significantly improve performance.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 5 Dec 2008 08:07:06 -0600

> My own experience of low bandwidth is that it is the CRL that kills it.

CRL != cert path.  Fast-Track optimizes the cost of the cert path.  If
the CRL is the issue then use the OCSP extension.

I do think that long cert paths will hurt, and that Fast-Track is not
likely to be very useful given RFC4507, but Stefan makes a good argument
for Fast-Track in the context of EAP-TLS (where it's even possible that
cert chains will be pre-loaded on clients, or cached for very long
times).

---

From: Yoav Nir <[email-masked]>
Date: Sun, 7 Dec 2008 10:16:33 +0200

> OK, Fast-Track for EAP-TLS makes more sense, thanks.

Yet another TLS use that makes sense, is DTLS. In UDP we don't have  
the acceleration and window of TCP, so each fragment needs to be  
acknowledged. This makes DTLS slow to set up when transmitting the  
whole certificate chain.

Email secured by Check Point
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 07 Dec 2008 07:46:19 -0800

At Sun, 7 Dec 2008 10:16:33 +0200,
> acknowledged. This makes DTLS slow to set up when transmitting the  

This actually isn't correct. DTLS doesn't have acknowledgements or
windowing at all. Rather, each side is supposed to just send it's
entire flight of messages at once and the message from the other
side is the ACK for the entire flight. If a packet goes missing,
you retransmit everything. We did consider an explicit ACK design
but decided this was a better compromise.

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Sun, 7 Dec 2008 21:38:57 +0200

> but decided this was a better compromise.

Thanks.  So it's fragmentation (instead of segmentation) without the  
benefit of TCP path MTU discovery.

That's an even better reason to make the flight of messages shorter.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Nelson B Bolyard <[email-masked]>
Date: Mon, 08 Dec 2008 10:35:39 -0800

> As I see it RFC4507 should terminate all interest in Fast-Track.  No?

Nico (& others in this thread):

Why are you citing/discussing RFC 4507 when it has been obsoleted by
RFC 5077 ?
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Dec 2008 14:17:31 -0600

> Why are you citing/discussing RFC 4507 when it has been obsoleted by

Because that's news to me!  Thanks for the correction :)
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 9 Dec 2008 15:03:10 +0000

Comments on some points made here.

On the revocation issue:
For that reason we cache and pre-fetch CRLs upon expire, and if that is not good enough we can use OCSP. In particular Lightweight OCSP (RFC 5019) is designed to solve the problems for massive scalable server certificate revocation checking. So caching server certificates still allows a big optimization.

Comparing with RFC 5077:
There is a considerable difference between fast-track and session resumption by the fact that fast-track is client caching and client initiated while session resumption requires server side caching per client. This and other differences mentioned makes a fast-track solution very useful also in situations where session resumption is not a realistic alternative.

Cached parameters:
Fast-Track lists a lot of parameters that are cached and hashed. I'm happy with only hashing the server cert chain. Does anyone have a strong wish to add anything else?

Stefan Santesson
Senior Program Manager

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 9 Dec 2008 08:37:30 -0800

> Behalf Of Stefan Santesson
> Sent: Tuesday, December 09, 2008 7:03 AM
> To: [email-masked]
> For that reason we cache and pre-fetch CRLs upon expire, and 
> if that is not good enough we can use OCSP. In particular 
> Lightweight OCSP (RFC 5019) is designed to solve the problems 
> for massive scalable server certificate revocation checking. 
> So caching server certificates still allows a big optimization.
> 
> Comparing with RFC 5077:
> There is a considerable difference between fast-track and 
> session resumption by the fact that fast-track is client 
> caching and client initiated while session resumption 
> requires server side caching per client. This and other 
> differences mentioned makes a fast-track solution very useful 
> also in situations where session resumption is not a 
> realistic alternative.
> 
> Cached parameters:
> Fast-Track lists a lot of parameters that are cached and 
> hashed. I'm happy with only hashing the server cert chain. 
> Does anyone have a strong wish to add anything else?
> 
[Joe] I'd like to see a way to avoid the trusted CA list.  Ideally the
client would be able to signal that it is not at all interested in this
information.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Dec 2008 08:44:31 +0000

> From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> Sent: den 9 december 2008 17:38
> To: Stefan Santesson; [email-masked]
> Subject: RE: [TLS] TLS Fast-Track resurrected?
> >
> > Cached parameters:

I think this can be solved automatically.
The client only need to hash the server certificate, without the path, to indicate that it is capable of using and validating this certificate.
The response from the server, if granting the client request, is to omit sending the whole path.

This works both if the client is using the path originally offered by the server, or if the client is validating the server certificate through an alternative path.

The question I have still is if there is anything else, more than the actual server certificate, that is worth including among the hashed parameters.

Stefan Santesson
Senior Program Manager

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Dec 2008 19:47:38 +0100 (MET)

Stefan Santesson wrote:
> The client only need to hash the server certificate, without the path,
> to indicate that it is capable of using and validating this certificate.

What Joe seems to be asking for is the caching of the certificate_authorities
list from the CertificateRequest message (the only "trusted CA list" that
gets transferred during a regular full SSL/TLS handshake when 
SSL client cert authentication is requested/offered by the server.

> The response from the server, if granting the client request, is to omit

Ouch -- please NO, don't do this.  The server should either send
the whole chain of certs according to the SSL/TLS specs or, if some kind
of fast-track caching is going to be used, omit all certificates.

Features and strategies of the PKI certificate path validation engine
is outside of the scope of the TLS handshake, the client is not required
to use the exact path that the server sends. 

And for simplicity of the design of a fast-track extension, the
protocol elements that the client caches (and the server may then
omit from the handshake) should be exactly as they originally appeared
on the wire. 

> 
> The question I have still is if there is anything else, more than the
> actual server certificate, that is worth including among the hashed
> parameters.

As I indicated, with much simpler TLS-extension you can easily extend
the list of static (server) parameters that the client can cache and the
server can omit from the handshake.  (Actually, it would even be possible
for the client to send along a hash of his own forward certification
chain and the server could signal in the server hello extension that
he does already have that information and the client may omit the
client certificate chain in his ClientCertificate handshake message.)

The existing fast-track I-D approach is IMHO overkill for the task
at hand.  A simpler approach that defines the list and tags
for a fast-track client hello extension, the contents of the
server hello extension that tells the client the server will try
to omit data from the handshake and replacement markers for the
data that the server actually omits from the regular handshake
messages will be sufficient.   This allows client and servers
to add support for fast-tracking particular (static) data
from a full TLS handshake whenever they feel like it with
a minimal impact on the existing codebase.

If the client doesn't announce a tag for a particular piece
of data from a previous full handshake with a server, the server
is not allowed to omit it from the handshake and the client
does not need to modify the parsing of the handshake
message (in order to recognize the omission tag instead
of the normal payload).

If the server doesn't recognize some of the tagged hashes from
the client, it can simply ignore them.

-Martin

---

From: Mike <[email-masked]>
Date: Thu, 11 Dec 2008 11:54:38 -0800

Martin,

There are a few problems with your approach (below).  First is the use
of hashes because if both the client and server need to calculate them,
there needs to be a negotiation as to what hash function to use.  Instead,
let the server specify an identifier (which could be a hash, or something
else), and have the client regurgitate it upon reconnecting.  This avoids
the need for hash agility.

Second, it's not a good idea to have a single extension modify the TLS
handshake in more than one way.  A cached_server_certificate extension
would make the server Certificate message optional, but otherwise change
nothing else about the handshake.  I outlined how this extension would
work in a previous message.

Third, not every cache-able piece of data is optimally handled in this
way.  For example, the server Diffie-Hellman parameters could be specified
as being one of the groups from RFCs 2409, 3526, or 5114, or a custom
group.  You would need a specialized extension to handle the details, and
since the ServerKeyExchange message would be modified (omit 'p' and 'g'),
you would want it to be done in its own extension according to the second
point above.  And as an added bonus, you could make use of the 'q' value
where available, further speeding up the handshake for DHE cipher suites.

Mike

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Dec 2008 20:45:33 +0000

Martin,

It seems that you totally misunderstood what I was saying.

> of fast-track caching is going to be used, omit all certificates.

... is exactly what I proposed.

> to use the exact path that the server sends.

... is also exactly what I propose

> omit from the handshake) should be exactly as they originally appeared

Well, the server certificate is in my proposal is hashed exactly as I appears on the wire. There is no need to hash anything but the server certificate.

For the rest I would agree with Mike, I would like to avoid a general full flexible model here, unless it is needed which I don't believe it is.

Stefan Santesson
Senior Program Manager

> Sent: den 11 december 2008 19:48
> To: Stefan Santesson
> Cc: [email-masked]; [email-masked]
> > The response from the server, if granting the client request, is to
> omit
> > sending the whole path.
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 11 Dec 2008 15:14:06 -0800

I was referring to the CA list that may be sent by the server in the
certificate request

   struct {
       ClientCertificateType certificate_types<1..2^8-1>;
       DistinguishedName certificate_authorities<0..2^16-1>;
   } CertificateRequest; 

In some cases this list can be quite long.  There are also many cases
where the client is not interested in this information.  Ideally the
client could state that it is not interested in this information so it
would not be sent.  It would probably also be useful for the client to
provide indication of information that it has cached and the server
would send the list if an update was necessary.  

Joe  

> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Thursday, December 11, 2008 12:46 PM
> To: [email-masked]
> Cc: Joseph Salowey (jsalowey); [email-masked]
> > Ouch -- please NO, don't do this.  The server should either 
> send the 
> > whole chain of certs according to the SSL/TLS specs or, if 
> some kind 
> > is outside of the scope of the TLS handshake, the client is not 
> > required to use the exact path that the server sends.
> 
> > protocol elements that the client caches (and the server 
> may then omit 
> > from the handshake) should be exactly as they originally 
> appeared on 
> > the wire.
> 
> Well, the server certificate is in my proposal is hashed 
> exactly as I appears on the wire. There is no need to hash 
> anything but the server certificate.
> 
> For the rest I would agree with Mike, I would like to avoid a 
> general full flexible model here, unless it is needed which I 
> don't believe it is.
> 
> 
> 
> Stefan Santesson
> Senior Program Manager
> > > > [Joe] I'd like to see a way to avoid the trusted CA 
> list.  Ideally
> > the
> > > > client would be able to signal that it is not at all 
> interested in
> > this
> > > > information.
> > >
> > What Joe seems to be asking for is the caching of the 
> > certificate_authorities list from the CertificateRequest 
> message (the 
> > only "trusted CA list"
> > that
> > gets transferred during a regular full SSL/TLS handshake when SSL 
> > client cert authentication is requested/offered by the server.
> >
> > >
> > Ouch -- please NO, don't do this.  The server should either 
> send the 
> > whole chain of certs according to the SSL/TLS specs or, if 
> some kind 
> > is outside of the scope of the TLS handshake, the client is not 
> > required to use the exact path that the server sends.
> >
> > protocol elements that the client caches (and the server 
> may then omit 
> > from the handshake) should be exactly as they originally 
> appeared on 
> > the wire.
> >
> > >
> > > The question I have still is if there is anything else, more than 
> > > the actual server certificate, that is worth including among the 
> > > hashed parameters.
> >
> > the list of static (server) parameters that the client can 
> cache and 
> > the server can omit from the handshake.  (Actually, it 
> would even be 
> > possible for the client to send along a hash of his own forward 
> > certification chain and the server could signal in the server hello 
> > extension that he does already have that information and the client 
> > may omit the client certificate chain in his ClientCertificate 
> > handshake message.)
> >
> >
> > The existing fast-track I-D approach is IMHO overkill for 
> the task at 
> > hand.  A simpler approach that defines the list and tags for a 
> > fast-track client hello extension, the contents of the server hello 
> > extension that tells the client the server will try to omit 
> data from 
> > the handshake and replacement markers for the data that the server 
> > actually omits from the regular handshake
> from a full 
> > TLS handshake whenever they feel like it with a minimal 
> impact on the 
> > existing codebase.
> >
> > If the client doesn't announce a tag for a particular piece of data 
> > from a previous full handshake with a server, the server is not 
> > allowed to omit it from the handshake and the client does 
> not need to 
> > modify the parsing of the handshake message (in order to 
> recognize the 
> > omission tag instead of the normal payload).
> >
> > If the server doesn't recognize some of the tagged hashes from the 
> > client, it can simply ignore them.
> >
> > -Martin
> >
> 
>

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Dec 2008 01:15:13 +0100 (MET)

> the need for hash agility.

You already solved that non-problem yourself:

If an identifier that is (cryptographically) unrelated to the cached
information is sufficient, then we will NOT NEED hash agility and
be just fine with SHA1 (which is a requirement for a lot of things
including the SSLv3 -> TLS 1.1 PRFs.

> work in a previous message.

Just the opposite.  A simple and generic extension can be reused
quite easily, and will result in less complexity, less code and
less bugs and be more attractive to implementors.

I don't like the idea of dropping the entire handshake message, because
it will require more code changes, even require major redesign on some
existing SSL/TLS state machines, for *NO* benefit.

If the task is to cache the Server Certificate (chain), then the
solution should do just that -- omit the Server Certificate Chain
from the Handshake if the client suggest it and the server determines
a match -- but do NOT drop the entire Handshake message because
this would change the entire handshake process.

> where available, further speeding up the handshake for DHE cipher suites.

Come on, apply your own creativity.  You can expand the list
to contain 3 pieces of information per entry instead of just two
if that suits you better:

  - a tag (that indicates which information from the handshake the
    client already has)
  - a tag that indicates how that information is identified
    (hash or identifier or whathaveyou)
  - the hash, identifier or whathaveyou

Why should we require 10 individual TLS extension where a single
one could solve all of the problems.

I'm puzzled why so many proposals for TLS extensions suggest to massively
change the (flow or sequence) of the SSL/TLS handshake messages when none
of the problems that they're trying to solve has anything to do with
the flow or the sequence of these handshake messages?

If there is no urgent need to add, remove or reorder TLS handshake
messages in order to add some feature, then DON'T DO IT.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Dec 2008 01:29:15 +0100 (MET)

> It seems that you totally misunderstood what I was saying.

I replied to what you wrote.  It could be that you meant something else.

> 
> Well, the server certificate is in my proposal is hashed exactly
> as I appears on the wire. There is no need to hash anything but the
> server certificate.

Nope, that is wrong.

IF we talk about caching, then it is about not sending in a repeated
handshake that was sent in a previous handshake.

If the client would send only the hash of the server certificate
and the server would omit the entire chain, then this would
significantly change the entire handshake.

Imagine that the the admin of the server had for some reason changed,
corrupted or removed one of the servers CA certificates (but not the
servers certificate), then you would suddenly see a different behaviour
between clients that were using fast-track and those that would do
a full handshake, because the latter would fail because of the
servers changed configuration.

If the motivation is to do caching of static information from
the full SSL/TLS handshake, then one should focus on doing
exactly that, and not do unnecessary other changes that will
have subtle non-deterministic side effects.

> 
> For the rest I would agree with Mike, I would like to avoid a general
> full flexible model here, unless it is needed which I don't believe it is.

I don't think that I understand what model you are refering to.

The existing fast-track document suggests a complex massive change
of the entire handshake protocol and is therefore an all-or-nothing
approach with a huge impact on every TLS implementation, it is
not extensible to fast-track static information from other TLS extensions,
and may, in fact be mutually exclusive with many other TLS extensions.

-Martin

---

From: Mike <[email-masked]>
Date: Thu, 11 Dec 2008 19:42:02 -0800

> including the SSLv3 -> TLS 1.1 PRFs.

I'm confused -- are you attributing that last paragraph to me?  I don't
remember writing it if I did.  But although I agree with the fact that
SHA-1 should be fine, you will see future requirements saying your
software MUST NOT use SHA-1 just as you see that happening with MD5 now.
They won't care that it's only being used for its compression property.

Also if you go back to Stefan's original message, he suggested adding hash
agility.  That's why I addressed it.  As I stated above, you can avoid it
altogether by allowing the server to send an opaque value that the client
caches and returns upon reconnecting.

> less bugs and be more attractive to implementors.

As you can guess, I totally disagree.  In UNIX, the designers declared that
"everything is a file!" and were very happy with their generic interface of
open, lseek, read, write, and close.  Sorry, but in the real world you need
all the extra stuff that's been relegated to the ioctl function so you can
actually eject a CDROM, etc.

> existing SSL/TLS state machines, for *NO* benefit.

I'm OK with this.  In my own software it would require similar effort to
allow for a skipped server Certificate message, or just an empty list, so
it didn't seem important.  Thanks for pointing this out.

>   - the hash, identifier or whathaveyou

I don't see how this addresses what I said above....

> one could solve all of the problems.

We're talking about one for sure (server cert. caching), and one maybe
(trusted CA list in CertificateRequest).  They are pure optimizations.  The
idea in my third point above is more than just a pure optimization, but
adds new functionality.  Bundling it into fast-track doesn't make sense.
(I'm not going to pursue drafting a proposal myself, but would implement it
if it ever became a standard.)

> the flow or the sequence of these handshake messages?

I'm puzzled why you think I was suggesting that?  I thought that making the
server Certificate optional in the fast-track handshake would be easy to
implement because the only data point I have is my own code.  You pointed
out that it would be better to keep the message, but just leave the list of
certificates empty.  I totally agree that that's a better solution since it
has fewer changes.  That's why we discuss ideas as a group.

> messages in order to add some feature, then DON'T DO IT.

No disagreement there.

Mike

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 12 Dec 2008 08:19:32 +0000

Mike,

At a second thought I think you are right about hash agility.
The function of the hash is to create an identifier of something that is previously trusted.

Su yes, I think hash agility is overkill. But it might be useful to use hash anyway. We do have usages of e.g. SHA-1 and even MD5 in protocols where we don't care to provide hash agility because it has no security implication. So it could work here as well. An advantage with a hash relative to an opaque blob is that it can be recomputed when needed and does not need storing.

Stefan Santesson
Senior Program Manager

> Sent: den 12 december 2008 04:42
> To: [email-masked]

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 12 Dec 2008 10:35:30 +0000

Martin,

In line,

Stefan Santesson
Senior Program Manager

> Sent: den 12 december 2008 01:29
> To: Stefan Santesson
> Cc: [email-masked]; [email-masked]; [email-masked]

I'm afraid you didn't. It might be that you misunderstood what I was saying :)

> handshake that was sent in a previous handshake.

In the original fast-track yes, but that does not have to be so.
If we only cache the certificate, we would do a new handshake except the server would not send its server certificate.

> significantly change the entire handshake.

Not at all, the client and server have all chances to resolve that situation.

> servers changed configuration.

And why would they fail? I sense a common misunderstanding about PKI here. The list of CA certificates provided by the server is not authoritative in any way. It is simply the best guess of what the client need in order to successfully validate the server certificate. The client may at its own discretion use a completely different set of CA certificate to validate the server certificate.

The only information the server needs in order to know that the client already have, and is capable of validating, the server certificate, is a hash of that server certificate.

> have subtle non-deterministic side effects.

I don't believe we have any non-deterministic side effects.

> I don't think that I understand what model you are refering to.

The one you expressed in a previous mail:

    "As I indicated, with much simpler TLS-extension you can easily extend
    the list of static (server) parameters that the client can cache and
    the
    server can omit from the handshake.  (Actually, it would even be
    possible
    for the client to send along a hash of his own forward certification
    chain and the server could signal in the server hello extension that
    he does already have that information and the client may omit the
    client certificate chain in his ClientCertificate handshake message.)"

> and may, in fact be mutually exclusive with many other TLS extensions.

Here we fully agree again.
I'm after something much simpler than the original fast-track.

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Dec 2008 17:03:12 +0100 (MET)

Stefan Santesson wrote:
> If we only cache the certificate, we would do a new handshake except
> the server would not send its server certificate.

I see potential pitfalls with that approach and therefore I don't like it.
Only in case that the client would always and unconditionally ignore all
chain certificates following the server certificate when performing
certificate path validation, then this approach would reliably lead
to the same behaviour for the initial and the fast-tracked handshake.

However, this is unlikely to be generally true and much too easy to
get wrong in an implementation (and will not show in the kind of
interop tests that people normally do).

I would really prefer if "fast-track" would be only about re-using
(aka caching) information from a original full TLS handshake in order
to cut down on the data traffic of repeated full handshakes (assuming
that the much quicker&cheaper existing SSL/TLS session resumption
is not an option).

Using a hash about the exact representation of the data as an identifier
for the data to be omitted from a fast-tracked full TLS handshake is
the most reliable/robust approach.  If the hash doesn't match, the
server will send the original data instead and the client can update
his cache.

If an identifier unrelated to the actual data on-the-wire is used,
then client and server have no proof they're really refering to
exactly the same data.  If the is/gets out-of-sync for whatever
reason, the fast-tracked handshake using data-unrelated identifiers
will fail, and the client will have to (a) retry and (b) apply
heuristics whether a failure could be related to out-of-sync
data references by the unrelated identifier and the client will
have to OMIT the fast-track proposal from the next handshake in
order to recover -- otherwise the client will be stuck in an
endless error loop.

Using a hash derived from the on-the-wire data as an identifier,
the recovery will always be automatic, never cause any handshake
failures and the client can blindly assert the fast-track
identifiers in every client hello, this will never impair
recovery from situations where the server's configuration was
unexpectedly changed or the clients cache got corrupted.
(well, the exact behaviour with respect to client cache corruption
 depends on when the client computes the hash value over the cached data
 that it sends in the fast-track hello extension).

I *personally* don't have any scenarios where the "benefit" of a
fast-track extension will actually be worthwile (worth the effort).

In case that others have/know such scenarios and these do involve small
pieces of hardware (instead of PC-style equipment), then having
a quite reliable scheme of recovery after a blackout, power interruption,
hard reset or factory-default-reset might be worth considering. 
 
> Not at all, the client and server have all chances to resolve that situation.

It DOES change the handshake.  It WILL change the result of the
server certificate path validation if the client uses the chain
certificates provided by a server during an original full SSL handshake.

Picture this:

    - original full SSL handshake, server sends inadequate, incorrect or
      defective chain certificates.  The client caches all received
      certs (server cert plus chain certs), but the clients certificate
      path validation doesn't currently use the server-supplied chain certs
      and succeeds the TLS handshake and caches *ALL* the received certs.
    - all future full SSL handshakes are fast-tracked, but the client
      sends only the hash/identifier of the servers certificate
    - at some point, the servers chain certificates are fixed
    - client doesn't realize that the servers chain certificates
      have changed and can not update his cache because it is still
      fast-tracking with the hash/identifier for the servers cert only
    - something about the clients configuration is changed so that
      for successful verification it will suddenly need the servers
      chain certificates.  Because the inadequate/incorrect or defective
      chain certs are still cached along with the correct server cert,
      the verify now fails.

However, since the servers certificate has not changed, the fast-track
handshake will not be able to reocover automatically at this point.
The client will either have to flush the CORRECT server cert from his
cache or deliberately omit the fast-track extension from the handshake
in order to recover.

I strongly prefer to use reliable caching over hinting&assumptions
for a fast-track TLS extension, with an high probability that an
original full TLS handshake and a fast-tracked full handshake will
result in the exact same behaviour.

The use of hinting (using unrelated identifiers) instead of
hashes derived from the on-the-wire data or the use of hashes
over only a fraction of the data that is to be omitted can easily
jeopardize the robustness of fast-track, so it should be avoided
where possible. 

> I don't believe we have any non-deterministic side effects.

It is going to behave non-determinstic for the consumer of the
technology, who is going to observe that after some change of
his servers configuration, a fraction of the clients (from different
vendors) are suddenly unable to connect while others don't seem
to have problems, and reset/reboot of the clients fixes some
and breaks others.
 
Of course, it was a server configuration error, but diagnosing the
cause is difficult if the clients show a seemingly random
(aka non-deterministic) behaviour because the implementors didn't
think about the consequences of their implementation stategies of
a half-baked protocol that provides too many options.

The purpose of standardizing a protocol is to provide an amount of
certainty that most independent implementations are going to behave
in a similar, robust and predictable fashion.

So if we add the possibility for caching of static data from the
original full TLS handshake, we should design it in a simple,
generic and robust fashion so that it can be reused/extended
for every piece of information in the full TLS hanshake, including
any TLS extensions.  That is what good standards are about.  IMHO.

> I'm after something much simpler than the original fast-track.

I really appreciate that you mention this.

But it seems that I'm failing to convey my thoughts and concerns
about the original and newly proposed design elements and features
in a sufficiently comprehensible fashion.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 12 Dec 2008 12:56:11 -0800

Joseph Salowey (jsalowey) wrote, on 2008-12-11 15:14 PST:
> In some cases this list can be quite long. 

Indeed, there has been (and may still be) at least one server product that
always tries to send the entire CertificateRequest in a single TLS record,
even when it's longer than 16KB. :-/

> There are also many cases where the client is not interested in this
> information.  Ideally the client could state that it is not interested in
> this information so it would not be sent.

How about a client hello extension that says "Don't ask me to do client
authentication with a cert, because I can't." ?

The protocol already assumes that the client can do client auth.  If that
was not so, I would suggest a client hello extension saying "I CAN do
client authentication with a cert", because that would be the exception
rather than the rule.

---

From: Mike <[email-masked]>
Date: Fri, 12 Dec 2008 13:13:46 -0800

> order to recover -- otherwise the client will be stuck in an

This is a good argument for hashing.  But then the question becomes
which hash function to use.  I'm sure that today MD5 would cause
concern, though for this purpose there's no need for a cryptographic
hash function.  You could argue that SHA-1 would be acceptable today.
But what about in 2 years, 5 years, or more?

> fast-track extension will actually be worthwile (worth the effort).

The best example I have is the www.etrade.com server.  Around the
time of the opening bell on Wall Street (9:30am Eastern time zone),
you can imagine that thousands/millions of customers log in to watch
the market.  E*Trade only supports HTTPS, not vanilla HTTP, so every
single connection uses TLS, and so every day at roughly the same time,
they need to establish new sessions for all these clients.  Server
cert. caching would eliminate possibly a couple kB per connection,
which could be substantial when packed into such a short time frame.

> any TLS extensions.  That is what good standards are about.  IMHO.

As a counter-example, I'll again point to the server Diffie-Hellman
parameters.  In order to cache that, you only want to cache p and g,
not Ys.  This would therefore not fit the "generic" method you are
advocating -- information about the specific message needs to be
taken into account.

Mike

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 12 Dec 2008 13:36:14 -0800

> Behalf Of Nelson B Bolyard
> Sent: Friday, December 12, 2008 12:56 PM
> To: [email-masked]
> Indeed, there has been (and may still be) at least one server 
> product that always tries to send the entire 
> CertificateRequest in a single TLS record, even when it's 
> longer than 16KB. :-/
> 
> > information.  Ideally the client could state that it is not 
> interested 
> > in this information so it would not be sent.
> 
> How about a client hello extension that says "Don't ask me to 
> do client authentication with a cert, because I can't." ?
> 
[Joe] In some cases the client can do auth, but will only ever have one
certificate and will not really be able to do anything with the list
except abort if it doesn't have the required cert. 

> The protocol already assumes that the client can do client 
> auth.  If that was not so, I would suggest a client hello 
> extension saying "I CAN do client authentication with a 
> cert", because that would be the exception rather than the rule.
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 12 Dec 2008 13:44:57 -0800

> > heuristics whether a failure could be related to out-of-sync data 
> > references by the unrelated identifier and the client will have to 
> > OMIT the fast-track proposal from the next handshake in order to 
> > recover -- otherwise the client will be stuck in an endless error 
> > loop.
> 
> This is a good argument for hashing.  But then the question 
> becomes which hash function to use.  I'm sure that today MD5 
> would cause concern, though for this purpose there's no need 
> for a cryptographic hash function.  You could argue that 
> SHA-1 would be acceptable today.
[Joe] This illustrates the point that EKR was making at the SAAG meeting
in the IETF meeting.  This may be a case where a hash function is
useful, but the properties of a cryptographic hash function are not
needed.  He proposed defining a non cryptographic hash function (such as
a CRC) for this purpose to clearly delineate between cases that require
the properties of a cryptographic hash and those that don't.  We
typically do a poor job of documenting what properties we need from a
hash function (cryptographic or otherwise) so it is often difficult to
say how a particular flaw in a hash function effects a particular usage.

If you choose to use a hash function you should determine what
properties you are relying upon, select an appropriate algorithm and
document the required properties.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 17 Dec 2008 13:32:56 +0000

Martin,

Thank you for taking the time and effort to provide a good and elaborate explanation of your concern.
You are making a valid point and I'm first in line to acknowledge the value of not only assuming the perfect world.

I do think that the problem you highlight could be auto-recovered in just the way you mention. That is, if a fast-track handshake fails due to failed server certificate validation, the client would automatically flush its cache and reconnect with a normal handshake. The cache would then be updated and functionality restored.

However, to provide a full hash of the complete set of omitted data is a very easy principle that could be worth it for just that reason.
I would not oppose adapting your proposal in this regard.

Stefan Santesson
Senior Program Manager

> Sent: den 12 december 2008 17:03
> To: Stefan Santesson