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

From: Eric Rescorla <[email-masked]>
Date: Tue, 07 Apr 2009 08:46:07 -0700

Stefan,

As we discussed in SFO, I think this is a good idea, but I would
generalize it a bit. Your current syntax only supports cert
caching. I would add one more level of indirection:

      enum {
           cached_information(TBD), (65535)
      } ExtensionType;

      enum {
           certificate_chain(1), trusted_cas(2), (255)
      } CachedInformationType;

      struct {
           HashAlgorithm hash;
           opaque hash_value<1..255>;
      } CachedInformationHash;

      struct {
           CachedInformationType type;
           CachedInformationHash hashes<1..2^16-1>;
      } CachedInformation;

Note that this also supports the minimal level of hash agility
we discussed in the meeting.

-Ekr

---

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

Thank you Eric,

This looks great. I will get on with updating the draft next week after
Easter. Just a few questions.

Could you elaborate what would get hashed and cached when identifying the
type trusted_cas?

Should we allow hashing of multiple information types in the same extension?
E.g. like:

    struct {
    } CachedObject;

    struct {
         CachedObject cached_info<1..2^24-1>;;
    } CachedInformation;

/Stefan

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Apr 2009 06:43:12 -0700

At Fri, 10 Apr 2009 11:14:45 +0200,
> Could you elaborate what would get hashed and cached when identifying the

I was thinking CertificateRequest.certificate_authorities.

The problem with having it be the CertificateRequest is that 
the CR also serves as a request to authenticate. Maybe that's
OK though...

>          CachedObject cached_info<1..2^24-1>;;

You're totally right. That's what I meant. I just got lost in the syntax.

-Ekr

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 10 Apr 2009 10:05:53 -0700

For trusted CAs it would be useful if the client could indicate that it
does not want to receive the list even though it may not have
information cached.  This could be indicated by either allowing the
CachedInformationHash to be omitted or reserving a specific
hashAlgorithm in the client hello to indicate no interest in the
information.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: Tuesday, April 07, 2009 8:46 AM
> To: Stefan Santesson
> Cc: TLS wg
> Subject: Re: [TLS] New "Fast-Track" draft posted
> 
> Stefan,
> 
> As we discussed in SFO, I think this is a good idea, but I 
> would generalize it a bit. Your current syntax only supports 
> cert caching. I would add one more level of indirection:
> 
>       enum {
> Note that this also supports the minimal level of hash 
> agility we discussed in the meeting.
> 
> -Ekr
> 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

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

I'm sorry but I don't understand this proposal.

How can the client know that the CA is trusted if it has not previously
connected to the server?

Secondly I would not omit data from the handshake without replacing it with
a hash as it would alter the security properties of the TLS finished message
e.g. its value as channel binding token would be changed.

/Stefan

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 10 Apr 2009 16:43:26 -0700

The server can include a list of certificate_authorities in the
certificate request handshake message.   If the server is configured
with public CAs this list can be very long (longer that the certificate
chain).  In many cases the client has only one certificate or no
certificate, so the trusted CA information is useless to the client
because it has no choice to make.  This is really a request for the
server not to send this information so I don't see any problem with the
finished message.  

One option is to include this functionality in a single extension with
the hash optimization.  Another option would be to create a separate
extension that tells the server that the information is not needed.  My
preference would be to use the same extension if it isn't too difficult.

Does this help?

Thanks,

Joe

> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Friday, April 10, 2009 2:12 PM
> To: Joseph Salowey (jsalowey); Eric Rescorla; Stefan Santesson
> Cc: TLS wg
> How can the client know that the CA is trusted if it has not 
> previously connected to the server?
> 
> Secondly I would not omit data from the handshake without 
> replacing it with a hash as it would alter the security 
> properties of the TLS finished message e.g. its value as 
> channel binding token would be changed.
> 
> /Stefan
> 
> 
> > For trusted CAs it would be useful if the client could 
> indicate that 
> > it does not want to receive the list even though it may not have 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >> Eric Rescorla
> >> generalize it a bit. Your current syntax only supports 
> cert caching. 
> >> I would add one more level of indirection:
> >> 
> >>       enum {
> >> Note that this also supports the minimal level of hash agility we 
> >> discussed in the meeting.
> >> 
> >> -Ekr
> >> 
> >>

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 11 Apr 2009 02:03:37 +0200

Thank you,

Yes it helped a lot :)

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 12 Apr 2009 02:23:24 +0200

Thinking more about this I can't find a way to accomplish this that I feel
really comfortable with.

The current extension syntax follows a common and simple principle. That is,
this is an extension that supports caching, and the way to signal that you
have cached information is that you can provide a hash of it.

To allow you to signal that you don't want to receive information, not
because you have cached it, but simply because you don't ever want to
receive it, requires too much deviation from both the extension semantics as
well as its syntax.

I would rather let the client receive the CA information once and then
present its hash on every following occasion. I don't think it is worth the
effort to save the bandwidth also the very first time of connection.

/Stefan

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 13 Apr 2009 09:24:56 -0700

I see your point.  The current semantics would be an improvement over
the current situation.  

I wonder if it may still be worthwhile to optimize the initial case.
Does anyone see a separate extension to tell the server not to send
specific data such as the trusted CA list as useful?  

Thanks,

Joe

> Sent: Saturday, April 11, 2009 5:23 PM
> To: Joseph Salowey (jsalowey); Eric Rescorla
> Cc: TLS wg
> Thinking more about this I can't find a way to accomplish 
> this that I feel really comfortable with.
> 
> The current extension syntax follows a common and simple 
> principle. That is, this is an extension that supports 
> caching, and the way to signal that you have cached 
> information is that you can provide a hash of it.
> 
> To allow you to signal that you don't want to receive 
> information, not because you have cached it, but simply 
> because you don't ever want to receive it, requires too much 
> deviation from both the extension semantics as well as its syntax.
> 
> I would rather let the client receive the CA information once 
> and then present its hash on every following occasion. I 
> don't think it is worth the effort to save the bandwidth also 
> the very first time of connection.
> 
> /Stefan
> 
> 
> >> with public CAs this list can be very long (longer that the 
> >> certificate chain).  In many cases the client has only one 
> >> certificate or no certificate, so the trusted CA information is 
> >> useless to the client because it has no choice to make.  This is 
> >> really a request for the server not to send this information so I 
> >> don't see any problem with the finished message.
> >> 
> >> One option is to include this functionality in a single extension 
> >> with the hash optimization.  Another option would be to create a 
> >> separate extension that tells the server that the 
> information is not 
> >> needed.  My preference would be to use the same extension 
> if it isn't too difficult.
> >> 
> >> 
> >> Does this help?
> >> 
> >> Thanks,
> >> 
> >> Joe
> >> 
> replacing 
> >>> it with a hash as it would alter the security properties 
> of the TLS 
> >>> finished message e.g. its value as channel binding token would be 
> >>> changed.
> >>> 
> >>> /Stefan
> >>> 
> >>>

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Apr 2009 21:26:12 +0200 (MEST)

> server not to send this information so I don't see any problem with the

While I do mostly agree that omitting the list of certification_authorities
is probably not going to change the security properties of the TLS session,
I STRONGLY object to omitting that parameter.

Unless there is a clear requirement for a future TLS revision to ignore
unsolicited client certificates and "gracefully" continue the handshake
exactly as when the client did not send the unsolicited certificate,
then it is a serious problem to the TLS handshake to omit the list
of certification_authorities from the CertificateRequest handshake message.

With "unsolicited" client certificate I mean one for which the client
does could not positively confirm that the server will be able to
build a certification path to one of its trust anchors.

In SSLv3 and TLSv1.0 it was explicitly prohibited in the spec to omit
the certificate_authorities list.  Starting with TLS v1.1 it is allowed
as an option, but in general a pretty bad idea to do so (and in particular
it is a pretty dumb idea to create a Server where such a list can not
be configured).

Our (OEM) SSL implementation is going to fatally abort the SSL handshake
if the server is sent a client certificate for which it can not build
a certification path to one of its trust anchors -- and that is independent
from whether it requires a client certificate or only requests a
client certificate and would complete the handshake when the client
did not send one.

I previously raised two other serious problems with an empty
certification_authorities list:  it is significant problem for
the widespread use of multiple independent client certificates.

The issue with client certs is not so much different from those
plastic cards that almost everyone carries around in his wallet today--
most of us have more than one of them, and we really expect the
vendors/mechants to post signs of those cards that they accept
for everyone to see instead of going through trial-and-error loops
through all of your cards when trying to get access somewhere or
trying to pay.

The other issue was "credentials access", which may create unnecessary
and annoying user-popups to enter a pin/passphrase for client credentials
or entering of the PIN/Passphrase on a secure SmartCard terminal on
each access without the slightest confirmation that the use of
that credentials has any chance to succeed in case that the server
did NOT send a list of trusted certification authorities.

The one thing that the current TLS-spec does not address is
the PKI-free environment (which seems to be not uncommon).
For this, one should probably define a protocol element to
mean "I am willing to accept certain self-signed certs" in
the CertificateRequest message in addition to the announced
list of certification_authorities.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Apr 2009 21:41:11 +0200 (MEST)

>          CachedObject cached_info<1..2^24-1>;;

I'm wondering about the sizes of the cached objects here.
The maximum size of an SSL record is 2^14 plaintext plus something.

<1..2^16-1> is 64 KBytes and almost 4x the max size of an SSL record

<1..2^24-1> is 16 MBytes and almost 1024x the max size of an SSL record

I mean, I do understand that you really would want to cache such large
objects, but are we really going to have such large elements in a single
SSL handshake message?

I'm not a SSL/TLS implementor, but the largest size that seems to
occur in a regular SSL handshake seems to be a "feature" of the
Microsoft SSL/TLS implementation for certain handshake messages,
but still below 64KBytes.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 14:51:31 -0500

> The maximum size of an SSL record is 2^14 plaintext plus something.

That's what fragmentation is for :)

> <1..2^16-1> is 64 KBytes and almost 4x the max size of an SSL record

Lots of TLS 1.2 types are specified as being u pto 2^16-1 bytes...

> <1..2^24-1> is 16 MBytes and almost 1024x the max size of an SSL record

Yes, that strikes me as rather large for a TLS handshake message, yet
64KB strikes me as rather small (we're bound to run into that boundary).
So 2^24-1 seems like a reasonable next larger size.

Nico
--

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 15 Apr 2009 07:56:35 +0200

I agree that the boundaries for these messages are quite large, and I don't
suggest that anyone should try to use them to their limits :)

I just took these boundaries from what I have seen in similar TLS specs.

However, in this case I think we could safely use 2^16-1 for both as we only
ship hashes here.

/Stefan

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 16 Apr 2009 17:29:17 -0700

Hi Martin,

While there are cases where the client has multiple certificates to
choose from, there are also cases where the client only has one.  What
is a client without multiple certificates going to do with the
certificate authorities list if it receives one?  

If I understand you correctly, what you would expect in this case is
that the client would not authenticate with its certificate if it was
not rooted in the trust list.  This would prevent the fatal error in
your implementation and allow the handshake to continue and possibly
succeed or fail at a later point.   

I'm not sure I really see a problem here.  The client is not required to
send this extension.  If it has multiple certificates to choose from
then it shouldn't send an extension to suppress the list.  Likewise, the
server is not required to use the extension and may still send the list
if it is important for its implementation.  

I think there still is a question as to whether an extension to suppress
the list provides a significant improvement over the hashing scheme.    

Cheers,

Joe

> From: Martin Rex [mailto:[email-masked]] 
> Sent: Tuesday, April 14, 2009 12:26 PM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> certificate 
> > or no certificate, so the trusted CA information is useless to the 
> > client because it has no choice to make.  This is really a 
> request for 
> > the server not to send this information so I don't see any problem 
> > with the finished message.
> 
> While I do mostly agree that omitting the list of 
> certification_authorities is probably not going to change the 
> security properties of the TLS session, I STRONGLY object to 
> omitting that parameter.
> 
> Unless there is a clear requirement for a future TLS revision 
> to ignore unsolicited client certificates and "gracefully" 
> continue the handshake exactly as when the client did not 
> send the unsolicited certificate, then it is a serious 
> problem to the TLS handshake to omit the list of 
> certification_authorities from the CertificateRequest 
> handshake message.
> 
> With "unsolicited" client certificate I mean one for which 
> the client does could not positively confirm that the server 
> will be able to build a certification path to one of its 
> trust anchors.
> 
> In SSLv3 and TLSv1.0 it was explicitly prohibited in the spec 
> to omit the certificate_authorities list.  Starting with TLS 
> v1.1 it is allowed as an option, but in general a pretty bad 
> idea to do so (and in particular it is a pretty dumb idea to 
> create a Server where such a list can not be configured).
> 
> 
> Our (OEM) SSL implementation is going to fatally abort the 
> SSL handshake if the server is sent a client certificate for 
> which it can not build a certification path to one of its 
> trust anchors -- and that is independent from whether it 
> requires a client certificate or only requests a client 
> certificate and would complete the handshake when the client 
> did not send one.
> 
> 
> certification_authorities list:  it is significant problem 
> for the widespread use of multiple independent client certificates.
> 
> The issue with client certs is not so much different from 
> those plastic cards that almost everyone carries around in 
> his wallet today-- most of us have more than one of them, and 
> we really expect the vendors/mechants to post signs of those 
> cards that they accept for everyone to see instead of going 
> through trial-and-error loops through all of your cards when 
> trying to get access somewhere or trying to pay.
> 
> The other issue was "credentials access", which may create 
> unnecessary and annoying user-popups to enter a 
> pin/passphrase for client credentials or entering of the 
> PIN/Passphrase on a secure SmartCard terminal on each access 
> without the slightest confirmation that the use of that 
> credentials has any chance to succeed in case that the server

---

From: Nagendra Modadugu <[email-masked]>
Date: Tue, 28 Apr 2009 17:25:20 -0700

I'm joining the discussion a little bit late.  Is there still time to
consider 1-RTT version of the full-handshake described in "Fast-Track"
paper? (i.e. client sends the ClientKeyExchange message speculatively before
receiving the ServerHello).

- nagendra

2009/3/4 Stefan Santesson <[email-masked]>

>  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
>
> 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: Martin Rex <[email-masked]>
Date: Wed, 29 Apr 2009 03:14:18 +0200 (MEST)

> receiving the ServerHello).

To me, this looks more like a flawed assumption rather than a
"speculative action", because it is impossible to recover.

The idea behind the short cuts is that the server can continue
with the full handshake if the shortcut is not available for
whatever reason.  Sending a ClientKeyExchange based on
assumptions what the contents of the ServerHello will be
precludes the Server from making decisions to which it is
entiteled in the original TLS protocol, and the result can
easily be a fatal error, which means that the network communication
channel must be closed and reopened -- a recovery at the
TLS protocol level is impossible.

Having the Client send (protected) application data optimistically
following the Client Finished message without waiting for the
Server Finished seems like an acceptable optimization
if you badly need to cut down the number of round trips.

Such an optimization, however, may have a significant impact
on the semantics of SSL_connect for APIs like that of OpenSSL.

-Martin