Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted

From: "Brian Smith" <[email-masked]>
Date: Tue, 2 Feb 2010 02:50:15 -0600

I am very interested in the ideas that motivate the cached info extension.
It obviously makes sense for the client to tell the server that it already
knows the certificate, so that the server doesn't have to send the
certificate. But, if the client already knows the certificate, then it
already knows the server's public key. Consequently, it is wasteful for the
client NOT to send the ClientKeyExchange along with the client hello.
Without the ability to include the ClientKeyExchange with the ClientHello,
the cached-info extension would usually only slightly decrease the bandwidth
needed for handshaking--by zero to two packets in the majority of cases,
AFAICT. At the same time, it would provide no effect on latency. Latency
from the extra round-trips required by TLS is a much worse problem than the
handshake bandwidth for a lot of applications, especially mobile
applications.

Back in April, Martin Rex said that including the ClientKeyExchange
immediately after the ClientHello was a bad idea, because it made it
difficult for the server to fall back to a full handshake (see his message
quoted below). I agree, but there is a simple workaround: embed the
ClientKeyExchange (and/or the client Certificate message) in a hello
extension. 

I attempted to do this, reusing as much of the infrastructure from the
cached info extension as possible. In particular, I added the following
CachedInformationTypes in order to support :

   enum { ..., dh_p(3), dh_g(4), ... } 
        CachedInformationType;

dh_p and dh_g would be for the hash of the cached values of the DH group
from the server's ServerKeyExchange for EDH key exchange. Then, I created a
new hello extension that is simply a wrapper around the ClientKeyExchange:

   Enum { ..., early_client_key_exchange, 
               early_certificate, ... } ExtensionType;

For EDH key exchange: The client includes cached dh_p and dh_g values, and
includes the early_client_key_exchange extension. If the server agrees to
use the same dh_p and dh_g as the client cached, then it can omit those
values from its ServerKeyExchange message's ServerDHParams; the
ServerDHParams in its ServerKeyExchange would then just contain dh_Ys.
Further, since the server already has the client's server_key_exchange
message, it can compute the master_secret, so it can send its
ChangeCipherSpec and Finished messages immediately after ServerKeyExchange.
If the server doesn't want to use the cached dh_p and dh_g, then it would
fall back to a full ServerKeyExchange. If the client sees the
ServerKeyExchange it knows it needs to generate its own ClientKeyExchange;
otherwise it knows to omit it. RSA key exchange is similar, except the
cached dh_p, dh_g (if any) would be ignored, and ServerKeyExchange obviously
would not be sent.

I noticed that a hash isn't always the best representative of the cached
information. For example, for EDH key exchange, it would be better if there
was the option of identifying well-known Diffie-Hellman groups by their
16-bit IANA id, for servers that use the IKE Diffie-Hellman groups. Then a
client could realistically include the IDs of all the IANA-registered DH
groups it supports in every (initial) ClientHello; using hashes for this
would be unrealistic because they would make the ClientHello too big--in
particular, the ClientHello would be much more likely to spill over into
another packet. As another example, if the client "knows" the server will
ask for a certificate, then it can preemptively/opportunistically include
its certificate chain in another hello extension. In that case, it might
wish to compress and/or (as is often requested) encrypt it's cert chain when
it is wrapped in the hello extension. Or, the client and server could work
together to mint a RFC4366 URL to use as the cached identifier for the
client certificate chain. Consequently, I'm not sure that standardizing on a
generic mechanism that only supports/requires hashes as identifiers for
cached data is a good idea.

Also, IMO, something should be done so that a client never needs to send
multiple hashes of the same cached value in a ClientHello. For example, the
client could tell the server which hash algorithms it will support caching
for, and then the server can select which ONE of those algorithms it will
support, and tell the client (just like it does for cipher suites). Or, the
choice of algorithm could be fixed to be the same as the hash algorithm used
for the signature of the certificate itself; the client is guaranteed to
support and trust that algorithm if it is going to work with that server at
all.

Regards,
Brian

On *Wed, 29 Apr 2009* (a long time ago), Martin Rex wrote:
> Nagendra Modadugu wrote:
>> 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).
> 
> 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

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 02 Feb 2010 14:19:48 +0100

> I am very interested in the ideas that motivate the cached info extension.

Stefan can speak for his reasons, but I see significant advantage in
being able to cache the list of trusted CA certs that is sent from
server to client.  For whatever reasons (which likely include poor
server configuration), I've seen TLS handshakes in the wild that are as
large as 30-40kb which cause some operational pains.

The server certificate _chain_ (note that it is the entire chain that is
cached, not just the server certificate) also has potential of being
large (and growing over time, it seems, as more and more interesting
X.509 extensions are added).

I'm not sure how this relates to the rest of your e-mail though...

/Simon

---

From: Adam Langley <[email-masked]>
Date: Tue, 2 Feb 2010 08:45:30 -0500

On Tue, Feb 2, 2010 at 3:50 AM, Brian Smith <[email-masked]> wrote:
> certificate.

Indeed. I've been bugging the author of this draft to update it
somewhat(*) and repost here. I've also written implementations for
OpenSSL and NSS. Hopefully life can be injected into this draft.

(* Martin Rex requested that the server inform the client of the
degree of its support for cached-info, to save the clients uselessly
caching information. This seems like a good idea)

> But, if the client already knows the certificate, then it

Given a client-speaks-first protocol like HTTP (which I happen to be
mostly concerned with), this could cut the full handshake from two to
one round trips.

However, there's a much easier way of doing this: cut through mode. In
this scheme the client starts sending application data records without
waiting for the server's Finished message so long as the ciphersuite
is sufficiently strong. Android already does this.

However, with cached certificates it's possible to get a full
handshake down to 0-RTT if the client can choose the server's random.
This means that the server has to be able to assert that it will never
reuse the same random, but that's doable if you assume some degree of
clock synchronisation and client-cached epoch values.

This idea has been banging about for a while now and you're the second
person that I've seen mention something similar in a week. I intend to
start experimenting with this, hopefully this quarter.

AGL

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 2 Feb 2010 09:16:23 -0600

> large as 30-40kb which cause some operational pains.

I didn't phrase this clearly. What I meant to say is "I find the cached info
extension interesting because optimizing the handshake is very important to
me."

> The server certificate _chain_ (note that it is the entire chain that
> is cached, not just the server certificate) also has potential of being

Agreed. My suggestion is really just trying to extend the usefulness of this
extension to the case where the certificate chain is not large.

Cheers,
Brian

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 02 Feb 2010 16:32:07 +0100

Adam Langley wrote:
[...]
> is sufficiently strong. Android already does this.

What if I modify the server's messages, so you negotiate to a
ciphersuite I can break, or I can derive information from (say the
length of the plaintext data you send- as with rc4). You will not detect
my attack until you receive the server's finished message, wouldn't you?

I think this mode is walking on the edge.

regards,
Nikos

---

From: Adam Langley <[email-masked]>
Date: Tue, 2 Feb 2010 10:41:07 -0500

> I think this mode is walking on the edge.

Obviously, if the server can cause the client to use a NULL cipher (or
something very weak) then cut through should not be used. For Android,
cut through mode will not be used if the cipher key length is less
than 128 bits.

The length of the application data records are observable on the wire
in any case. The only advantage that an attacker could gain here is to
choose a cipher that doesn't pad records to get a slighter more
accurate length.

Given how extremely valuable saving a round trip is, we choose to make
this tradeoff.

AGL

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 02 Feb 2010 07:52:56 -0800

> is sufficiently strong. Android already does this.

I'm not a cryptographer, but it seems to me that sending data over
the connection before it is validated is a very bad idea.  On my
test server, people have established connections in less than 40 ms
using a full handshake.  Most handshakes from around the world
complete in less than half a second.  Don't get too carried away
trying to optimize this, especially if you're not able to maintain
the security guarantees.

Mike

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 02 Feb 2010 17:18:50 +0100

> choose a cipher that doesn't pad records to get a slighter more

TLS uses random padding in block cipher thus length is typically not
observable unless of course if random padding is not used.

regards,
Nikos

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 2 Feb 2010 10:19:57 -0600

Adam Langley wrote:
> > already knows the server's public key. Consequently, it is
> > wasteful for the client NOT to send the ClientKeyExchange
> > along with the client hello.
> 

Interesting. Please send me links to some info about the Android way, if you have any. In particular, have you run into any compatibility problems with this approach? AFAICT, my (private) implementation would abort the connection if there was anything following the ClientHello before it sent its ServerHello.

I am more interested the ephemeral modes, which would always require one round-trip even in cut-through mode. That is why I think The "cut-through" mode Android is using says "I don't care if the ServerHello was tampered with, because the parts that affect security (ciphersuite, protocol version) are good enough for me." I agree that seems like a safe optimization in many cases. However, I think the exact details have to be very thoroughly researched and documented very well if this is an optimization that we are going to encourage. I feel my suggestion is preferable because it has NO material effect on the security properties of TLS at all. Plus, it works for server-speaks-first protocols like SMTP and IMAP (also relevant for you, AFAICT) where the server speaks first.

More below.

> clock synchronisation and client-cached epoch values.

Hopefully soon I will get around to proposing another extension: the "RequestTickets" extension. Basically, the client includes an empty extension with extension_type=RequestTicket in ClientHello. The server responses with the same in its ServerHello if it supports it. If the server does so, then at any time *AFTER* the ChangeCipherSpec messages, the client can send a message with record_type=RequestTickets, which contains a single byte, <N>. That byte indicates that the client wants the server to give it <N> RFC5077 session tickets. The server responds with its own RequestTickets record, which contains a vector of RFC5077 session tickets for use on subsequent connections. The purpose of this extension is to allow a client to resume a session with a server, without outside observers being able to tell *which* session is being resumed (IMO, this is a major flaw with RFC5077; I don't understand why RFC5077 didn't at least put the NewSessionTicket handshake message after the server change_cipher_spec message).

You could easily extend this RequestTickets mechanism so that the server returns a vector of (ServerRandom, Session Ticket) pairs. Then the server could still choose its own random value, but it would do so ahead of time. The session ticket should include an authenticator for the ServerRandom. Then, resuming connections would include an "early_server_random" extension alongside the SessionTicket extension, and the client could send client_hello||change_cipher_spec||finished||application_data in its resuming connections. But, then you are open to replay attacks, AFAICT.

> start experimenting with this, hopefully this quarter.

Keep in touch. Sometime this quarter I hope to do a proof-of-concept implementation server implementation for OpenSSL.

Regards,
Brian

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 2 Feb 2010 11:37:56 -0600

Adam,

Besides SPDY, the next protocol extension is useful for another case: Running HTTP, SMTP, and/or IMAP services on the same port (usually 443). For example, it could be used to make it difficult to tell if a user is sending (SMTP) or receiving (IMAP) email, if padding is done appropriately. I think this is a very valuable addition. It is hard to do without a TLS extension because HTTP is a client-speaks-first protocol, and SMTP and IMAP are server-speaks-first protocols.

My understanding is that SPDY will always require TLS, right? If so, then TLS w/ TLS compression + HTTP pipelining seem to offer most/all of the benefits of SPDY except (a) the simplified HTTP header parsing, and (b) the multiplexing. I don't really see the advantage of the HTTP header syntax changes considering the large amount of computation needed for (de)compression and (de/en)cryption. So, why not recast SPDY as a "canonical HTTP header lexical syntax" profile + HTTP pipelining + TLS + TLS w/ TLS compression + a TLS stream multiplexing extension?

IMO, a stream multiplexing extension would be generally useful because it frustrates traffic analysis, and it could be used for more effective padding than the minimal/inefficient padding that TLS CBC mode offers (simply multiplex a no-op stream along with your real data streams). Also, AFAICT, TLS doesn't provide any padding facility at all for stream (e.g. RC4) or AEAD cipher suites (AES-GCM in particular).

Regards,
Brian

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 2 Feb 2010 12:06:16 -0600

Michael D'Errico wrote:
> Adam Langley wrote:
> > However, there's a much easier way of doing this: cut through mode.
> > In this scheme the client starts sending application data records
> > without waiting for the server's Finished message so long as the
> > ciphersuite is sufficiently strong. Android already does this.
> 

Half a second is not an acceptable latency for many applications, especially
over GPRS (even "3G"/"4G") connections. I developed my own HTTP+TLS stack
for a mobile app just to reduce the latency to acceptable levels. Plus,
ephemeral key exchange can add noticeable latency when the client's
processor is weak--which again is the case especially for mobile apps. (The
OS's TLS stack didn't provide adequate control over the session cache,
didn't support compression, and didn't support session tickets.) 

Latency concerns seem to be a strong motivation for people to develop new
protocols less secure than TLS like OAuth, and to choose non-ephemeral
key-exchange over ephemeral key exchange. A safe zero-roundtrip
handshake--even just for resumption--would make TLS practical for many more
applications and would reduce pressure for apps to provide the user a switch
to "turn off security" as many mobile apps are doing. If Adam or anybody
else has already tried to work out a mechanism for that, I'd love to hear
about it.

Cheers,
Brian

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 02 Feb 2010 12:15:17 -0800

Brian Smith wrote:
>> On my

I'm only in control of one side of the TLS connection in the numbers I
presented, so some of the delay can be attributed to the client software.

I just did some tests on my MacBookPro to eliminate the uncertainty of
the client software and the network latency factor.  Here are the times
to establish a full handshake for a few cipher suites:

     003D - RSA (1024) AES-256 SHA-256 + session ticket:            10 ms
     003D - RSA (1024) AES-256 SHA-256 (normal session):           8.5 ms

     006B - DHE_RSA (1024/1024) AES-256 SHA-256 + session ticket:   72 ms
     006B - DHE_RSA (1024/1024) AES-256 SHA-256:                    71 ms

     006A - DHE_DSS (1024/1024) AES-256 SHA-256 + session ticket:   72 ms
     006A - DHE_DSS (1024/1024) AES-256 SHA-256:                    71 ms

when the DH parameters are 1536-bit:

     006B - DHE_RSA (1536/1024) AES-256 SHA-256 + session ticket:  202 ms
     006B - DHE_RSA (1536/1024) AES-256 SHA-256:                   201 ms

So you can see that forward secrecy costs a lot in terms of latency, even
for a fast processor.

The timing for session resumption is independent of the key exchange
mechanism:

     AES-256 SHA-256 + session ticket:        4.2 ms
     AES-256 SHA-256:                         1.2 ms

Here you can see that server-side session caches are considerably faster
than session ticket resumption (at least in my code).

> else has already tried to work out a mechanism for that, I'd love to hear

What you are trying to do is not bad, but it doesn't seem to fit well
with the existing TLS protocol.  It seems like you want the client to
send a "packet" to the server, which simultaneously authenticates the
server, establishes the keys, and delivers a payload.  I'm not sure
that trying to twist TLS into this shape is the correct approach.

Mike

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 03 Feb 2010 11:06:10 +0100

Adam,

> OpenSSL and NSS. Hopefully life can be injected into this draft.

I asked the WG chairs to proceed and WG last call this document around last
IETF in Hiroshima, to find out if its done or whether it needs more WG
processing.

The reason this has not happened is because Joe wanted to give the
renegotiation issue all the focus of the WG.

I'm happy to bring this draft into completion and publication.

I will comment on the technical issues separately.

/Stefan

---

From: Adam Langley <[email-masked]>
Date: Wed, 3 Feb 2010 05:18:41 -0500

> I'm happy to bring this draft into completion and publication.

I came off as a lot more grouchy than I had intended in the above,
sorry about that!

AGL

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 18 Feb 2010 14:16:11 +0100

All,

Going back to address this original mail which I think is the only one
proposing any alteration of the current draft.

Brian,

The client don't know if the cached server certificate is acceptable for the
handshake before the server has acknowledged that is is correct. Sending a
ClientKeyExchange with a Client Hello is therefore successful only if the
client has cached a server certificate and that certificate is acknowledged
by the server.

I'm not saying that your optimization isn't interesting, but it is not
generic to the cashed-info draft and would make the current draft
significantly more complex. I would prefer not to go there.

I think this draft is ready for WGLC without modifications.

/Stefan

On 10-02-02 9:50 AM, "Brian Smith" <[email-masked]> wrote:

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

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 18 Feb 2010 14:41:58 +0100

Well,

I went through my change list and have now updated and reposted the draft as
draft-03.

Changes can be viewed from:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-03.txt

Basically I have updated the boilerplates, removed one excessive ";"
character and reduced the size of CachedObject to 2^16-1 bytes (from 2^24-1
which is way more than needed).

I think this is NOW ready for WGLC

/Stefan

---

From: Adam Langley <[email-masked]>
Date: Thu, 18 Feb 2010 11:31:23 -0500

> I think this is NOW ready for WGLC

Wan-Teh Chang and I went over this draft yesterday and we sketched up
some changes to the draft that we think might be a good idea.

In outline:
   1) The extension is symmetrical, so the server can now predict
values from the client.
   2) Both sides can list the types of objects for which they support caching.
   3) Both sides can list the hash types which they support.
   4) Substitution of cached values now involves new handshake message types.
   5) Made it clearer that each substitution is optional and independent.

I don't feel particularly strongly about any of these points and would
much rather see the current draft than nothing at all.

1) makes the extension symmetrical and it seems like there might be
something in the future that the server would like to predict from the
client. At the moment we suggest that the server might want to support
predicting the client's certificate. Often a CertificateRequest
handshake is a renegotiation and a higher level knows what certificate
the client should be presenting.

2) was a suggestion from Martin Rex and 3) is a follow on from that.

4) results from the fact that I don't think the current draft is clear
enough about how the substitution occurs. Making new handshake types
means that everything is very explicit and I prefer that. However, I
can't think of anything technically wrong with just memcmp()ing for
the hash values in the existing handshake messages, if it was
precisely specified.

Cheers

AGL

3.  Cached Information Extension

   A new extension type (cached_information(TBD)) is defined and used in
   both the client hello and server hello messages.  The extension type
   is specified as follows.

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

   The "extension_data" field of this extension, when included in the
   client hello, SHALL contain "CachedInformation" according to the
   following structure:

   enum {
        server_certificate_chain(1),
        client_certificate_chain(2),
        trusted_cas(3),
        (255)
   } CachedInformationType;

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

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

   struct {
        CachedInformationType supported_types<0..255>;
        HashAlgorithm supported_hash_algorithms<0..255>;
        CachedObject cached_info<0..2^16-1>;
   } CachedInformation;

   Hash algorithm identifiers are provided by the RFC 5246 [RFC5246]
   HashAlgorithm registry.  Compliant implementations MUST support
   sha1(2) as HashAlgorithm.

   When CachedInformationType identifies server_certificate_chain or
   client_certificate_chain, then hash_value MUST include at least one
   hash value calculated over the certificate_list element of a
   Certificate message.

   When CachedInformationType identifies trusted_cas, then hash_value
   MUST include at least one hash value calculated over the
   certificate_authorities element of a server side CertificateRequest
   message.

   Implementations MUST NOT include hashes for multiple objects in the
   same CachedObject structure.  If more than one hash is present in the
   CachedObject structure, they MUST be hashes over the same information
   object using different hash algorithms.

   Implementations SHOULD NOT emit duplicate CachedInformationHashs
   (i.e. the same hash twice).

   Implementations SHOULD NOT emit duplicate CachedObjects (i.e. the
   same object twice).

   supported_types enumerates the set of objects that the peer might
   wish to cache.  This is advisory and may guide the peer when deciding
   whether to cache a given piece of information.  A host may still
   choose to substitute a cached object even if supported_types suggests
   that it is not able to.  There SHOULD NOT be any duplicates in the
   vector.

   supported_hash_algorithms enumerates the set of hash functions that
   the host supports.  Peers may use this to avoid sending hashes using
   an algorithm that is not supported.  This is advisory only, thus a
   host MAY substitute a hash value even if supported_hash_algorithms
   suggests that it is not able to.  There SHOULD NOT be any duplicates
   in the vector.

   Other specifications MAY define more CachedInformationType types.

4.  Message flow

   Clients MAY include an extension of type "cached_information" in the
   (extended) client hello.  Clients MAY need the ability to cache
   different values depending on other information in the Client Hello
   that modify what values the server uses, in particular the Server
   Name Indication [RFC4366] value.

   Servers that receive an extended client hello containing a
   "cached_information" extension, MAY indicate that they support
   caching of information objects by including an extension of type
   "cached_information" in their (extended) server hello.  The server's
   extension may predict values from the client, specifically the
   client's Certificate message, if any.

   Following a successful exchange of "cached_information" extensions,
   implementations may choose to substitute handshake messages as
   follows:

   A Certificate message MAY be replaced with a CertificateHash(TBD)
   message:

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

   A CertificateRequest message MAY be replaced with a
   CertificateRequestHash(TBD) message:

   struct {
        ClientCertificateType certificate_types<1..2^8-1>;
        SignatureAndHashAlgorithm
          supported_signature_algorithms<2^16-1>;
        HashAlgorithm hash;
        opaque hash_value<1..255>;
   } CertificateRequestHash;

   In each case, the hash and hash_value fields MUST come from the
   peer's list, as provided in its "cached_information" extension.

   The handshake protocol will proceed using the cached data as if no
   handshake message substitution had occured.  The Finished message
   will however be calculated over the actual data exchanged in the
   handshake protocol.

5.  Examples

   Consider the following handshake message that the server would
   typically transmit:

   0b                 # Handshake message type 11 (Certificate)
   00 00 10           # Handshake message length 16
   00 00 0d           # certificate_list length
   00 00 04           # ASN1.Cert length
   01 02 03 04        # certificate 1 bytes
   00 00 03           # ASN1.Cert length
   05 06 07           # certificate 2 bytes

   In order to predict this message, a client could send the following
   cached_info extension value:

   00 00 19           # cached_info length
   01                 # type (server_certificate_chain)
   00 16              # hashes length
   02                 # hash type (SHA1)
   14                 # hash length (20 bytes)
   8c 4b 89 c9 1c 6d 70 ef 07 53 bf c7 97 c1 ff e6 93 f0 6b 0c

   Where the SHA1 value is the hash of the following bytes:

   00 00 04
   01 02 03 04
   00 00 03
   05 06 07

   If the client correctly predicted the certificate data, and the
   server chose to substitute its Certificate message, then it would
   emit the following CertificateHash:

   xx                 # Handshake message type TDB (CertificateHash)
   00 00 16           # Handshake message length 22
   02                 # hash type (SHA1)
   14                 # hash length (20 bytes)
   8c 4b 89 c9 1c 6d 70 ef 07 53 bf c7 97 c1 ff e6 93 f0 6b 0c

6.  Security Considerations

   Hash algorithms used in this specification are required to have
   reasonable random properties in order to provide reasonably unique
   identifiers.  No serious security threat requires selected hash
   algorithms to have strong collision resistance.

7.  Acknowledgements

   This is substantially the work of S. Santesson (3xA Security).
   However, since he has not reviewed this deriviative version he is not
   listed as an author in case that mistakenly suggests his endorsement.

8.  IANA Considerations

   1.  Create an entry, cached_information(TBD), in the existing
       registry for ExtensionType (defined in RFC 5246 [RFC5246]).

   2.  Create entries for CertificateHash(TBD) and
       CertificateRequestHash(TBD), in th existing registry for
       HandshakeType (defined in RFC 5246 [RFC5246].

   3.  Establish a registry for TLS CachedInformationType values.  The
       first entries in the registry are server_certificate_chain(1),
       client_certificate_chain(2) and trusted_cas(3).  TLS
       CachedInformationType values in the inclusive range 0-63
       (decimal) are assigned via RFC 5226 [RFC5226] Standards Action.
       Values from the inclusive range 64-223 (decimal) are assigned via
       RFC 5226 Specification Required.  Values from the inclusive range
       224-255 (decimal) are reserved for RFC 5226 Private Use.

9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

---

From: Adam Langley <[email-masked]>
Date: Thu, 18 Feb 2010 11:55:18 -0500

> the client should be presenting.

wtc pointed out to me that this might be unclear. The situation that I
have in mind is this:

A user is using HTTPS to navigate a web site and reaches a point where
they need to authenticate. They enter their username in a text field
and hit "Login using certificate". This triggers a renegotiation with
a CertificateRequest and, at this point, the server knows the
certificate that the client should be presenting. The client could
even use this to guide the user in the selection of the certificate.

People might feel that this is a little contrived and I wouldn't mind
in the slightest if it was dropped. But it seems simpler that the
extension should be symmetrical and odd to assume that we'll never
need to predict anything from the client.

Cheers

AGL

---

From: Brian Smith <[email-masked]>
Date: Thu, 18 Feb 2010 12:04:13 -0600

> http://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-03.txt
I think it is especially important to have the SHA-1 requirement 
changed. It is a big hassle to require SHA-1 for compliance when now 
every use of SHA-1 has to be reviewed. Also, mandating SHA-1 would be in 
conflict with other requirements--especially requirements to follow NIST 
and NSA recommendations regarding algorithms. At a minimum, make SHA-1 
support mandatory only if/when the connection's negotiated version is 
less than TLS 1.2.

The client already has to calculate hashes of each certificate in the 
certificate chain, using algorithms fixed at the time each certificate 
was signed. The client and server implicitly trust all of these 
algorithms if they accept the certificate chains. X.509 libraries 
already provide efficient access to these hashes. Also, given the 
fingerprint of the sender's certificate, you can determine the entire 
certificate chain if all the certificates are available in the cache. 
Consequently, it would be much better if hash used for identifying a 
cached certificate was the same as the fingerprint of the sender's 
certificate, instead of a hash of the entire certificate chain using one 
or more other algorithms.

The server already told the client what hash algorithms it supports in 
CertificateRequest message from which the client extracted the cached 
certificate_authorities. The client can just pick *one* of those 
algorithms when hashing the certificate_authorities--most likely, the 
hash algorithm used by for the signature of its own certificate. I don't 
see why it's valuable for the client to be able to include multiple 
hashes in its ClientHello. In other words, I think CachedInformation 
should be removed and all uses of it replaced by CachedObject.

But, then you can go even farther and remove CachedObject and 
CachedInformationType:

enum { cached_certificate_chain(TBD), cached_trusted_cas(TBD), (65535) } 
ExtensionType;

The "extension_data" field of each of these extensions, when included in 
the client hello, SHALL contain CachedInformationHash according to the 
following structure:

struct {
     HashAlgorithm hash;

Then the server could indicate which items it supports by including 
empty extension(s) with the corresponding type(s), which is what most 
other extensions do.

Regards,
Brian

---

From: Brian Smith <[email-masked]>
Date: Thu, 18 Feb 2010 12:45:01 -0600

> the client should be presenting.
There's already the client certificate URL extension (RFC 3546 section 
3.3). I think that extension could/should be used for this specific use 
case, especially since it already defined the special CertificateURL 
message unless there's a specific reason it can't be used.
>    2) Both sides can list the types of objects for which they support caching.
I agree, but this is kind of predicated on the idea that there are going 
to be more items for which this extension is appropriate. There 
shouldn't be many large items in the handshake, and this extension + the 
client certificate URL extension already cover the existing large items. 
This extension may not even be appropriate for future item caching; it 
isn't optimal for caching ephemeral key exchange parameters that can be 
specified by name, for example, because the hash would be larger than 
the cached value.
>    3) Both sides can list the hash types which they support.
The hash negotiation for TLS seems to be designed so that every kind of 
usage of hashes can be negotiated separately. That's why TLS has a 
"supported_signature_algorithms" extension instead of a generic 
"supported_hash_algorithms" extension. To continue with that design 
would mean each type of cached item would need to have its own separate 
algorithm negotiation.
> the hash values in the existing handshake messages, if it was
I would say the message flow should just go something like this: If the 
server doesn't send a Certificate message, then use the cached 
certificate. If the server sends a CertificateRequest with an empty 
(zero-length) certificate_authorities then use the cached 
certificate_authorities. Then nobody has to do any substitution, it's 
much easier to specify, and much easier to implement than the 
substitution mechanism from the current draft or introducing new 
handshake messages would be. Note that this is how RFC5088 works (you 
have to infer what the server is saying based on what handshake messages 
it skips; for example, if the server doesn't send a Certificate right 
after its ServerHello then you have to infer that it's doing a 
resumption based on the given ticket).

Regards,
Brian

---

From: Brian Smith <[email-masked]>
Date: Thu, 18 Feb 2010 12:48:03 -0600

Brian Smith wrote:
> Note that this is how RFC5088 works
Typo. RFC5077.

- Brian

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 18 Feb 2010 14:00:19 -0500

The security considerations section already points out that collision
avoidance is not a requirement:

   Failure of a provided hash to correctly and uniquely
   identify the correct set of hashed parameters may at most lead to a
   failed TLS handshake followed by a new attempt without the cached
   information extension. No serious security threat requires selected
   hash algorithms to have strong collision resistance.

CRC32 would provide sufficient uniqueness for this application, but
since client libraries already include SHA-1, it is a convenient (albeit
slower and overqualified) substitute.  The interoperability benefit of
requiring support for a common algorithm:

   Compliant implementations MUST support "wxyz" as HashAlgorithm.

... far outweighs any conceivable benefit of not requiring support for a
common algorithm.   Algorithm agility, negotiation, and version
dependencies would be grotesque complexities in this context.

Dave

-----Original Message-----
From: Brian Smith

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 19 Feb 2010 09:38:36 +0100

+1 on Dave's comment here.

Note that SHA1 is "MUST support". It is not "MUST use".
You don't have to send a SHA1 hash, but if you do, you can be confident that
the recipient can handle it.

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Fri, 19 Feb 2010 15:03:52 +0100 (MET)

> support mandatory only if/when the connection's negotiated version is 

I assumed that NIST deprecated the use of SHA-1 only for digital signatures.
Implementations of TLS v1.0 and v1.1 may not support anything besides
SHA-1 within TLS yet.

The use of SHA-1 is not as security critical as you might think it is.
The _real_ data, identified by the hash, must still be processed, but
it is taken from the clients cache instead of being transferred
over the wire.

> certificate_authorities.

That is one of the non-obvious changes in TLS v1.2.
Prior versions (TLSv1.1,TLSv1.0,SSLv3) do not have a signature
algorithms element in the CertificateRequest message.

One IMHO of the biggest problems in the revised TLS specifications
is that it doesn't clearly document changes from prior protocol
versions.  rfc-5246 7.4.4. CertificateRequest ought to really
have mentioned in the description of "supported_signature_algorithms"
that this element was newly inserted into the CertificateRequest
message with TLSv1.2 and does not exist in prior versions of TLS/SSLv3.

> ... the server could indicate which items it supports by including 

I also think that reporting back in ServerHello for which elements
it supports caching would be a good idea.

-Martin

---

From: Brian Smith <[email-masked]>
Date: Fri, 19 Feb 2010 09:06:15 -0600

> I assumed that NIST deprecated the use of SHA-1 only for digital signatures.
 From http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html:

"Regardless of use, NIST encourages application and protocol designers 
to use the SHA-2 family of hash functions for all new applications and 
protocols. After 2010, Federal agencies may use SHA-1 only for the 
following applications: hash-based message authentication codes (HMACs); 
key derivation functions (KDFs); and random number generators (RNGs). "

Notice in particular that NIST has a whitelist of approved uses for 
SHA-1, not a blacklist.
> Implementations of TLS v1.0 and v1.1 may not support anything besides
This reasoning is backwards. A TLS 1.2 implementation doesn't need to 
implement SHA-1 at all, except for backward compatibility. A TLS 1.0/1.1 
implementation would need to be updated to support this extension 
anyway, and the addition of new hash algorithms can be done at the same 
time. Plus, TLS 1.0/1.1 implementations need to be upgraded to TLS 1.2 
anyway, specifically to avoid SHA-1 and MD5.

I already have TLS 1.2 software that contains only NSA Suite B 
algorithms, and that already follows the NIST recommendation to use 
SHA-2 for "all new applications." To implement this specification, I 
would have to add a non-suite-B algorithm to my software. While that is 
a minor technological problem (more code, more testing, more 
documentation), it is a bigger social problem, because it requires 
careful explanation to users/customers that SHA-1 is used, but it isn't 
used in a way that affects the security of the protocol. It is much 
easier to explain to customers that the software doesn't contain 
non-suite-B algorithms at all.
> it is taken from the clients cache instead of being transferred
Yes, I understand this and agree with it. But, it is still in conflict 
with NIST's recommendation, regardless.
> algorithms element in the CertificateRequest message.
That can be solved by simply hard-coding a hash algorithm for the TLS 
1.0 and TLS 1.1 implementations.

Regards,
Brian

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 19 Feb 2010 16:01:49 +0100

Brian and Adam,

> resumption based on the given ticket).

Breaking out this question in a separate thread.

I do not like the though of defining new handshake messages. We have a very
small name space for handshake messages with very strict rules for defining
new ones.

I like in principle your suggested simplification to omit whole handshake
messages to indicate substitution. However, this works only if the cached
parameter is the only parameter of the handshake message. I.e. It works for
the server Certificate message but not for the certificate_authorities
parameter of the CertificateRequest message.

I do however absolutely agree that the current document is underspecified as
to how the substitution is done. It also offers an alternative syntax for
the handshake message with hash substitution which may be a bit problematic.

As I see it we have two choices.

1) To define a format for the handshake message which include the hash
substitution using a syntax that alters the defined syntax of the handshake
message. (current draft approach)

2) To define a format which preserves the original handshake message syntax.

In practice this would look something like this:

Certificate handshake message:

Original syntax:
      opaque ASN.1Cert<1..2^24-1>;

      struct {
          ASN.1Cert certificate_list<0..2^24-1>;
      } Certificate;

Substitution syntax, choice 1 (current draft):
      struct {
          CachedInformationHash certificate_list<0..2^24-1>;
      } Certificate;

Substitution syntax, choice 2 (preserving original syntax):
      CachedInformationHash CachedCertList<1..2^24-1>;

      struct {
          CachedCertList certificate_list<0..2^24-1>;
      } Certificate;

The corresponding syntax for CertificateREquest;

Original syntax:
      opaque DistinguishedName<1..2^16-1>;

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

Substitution syntax, choice 1(current draft):
      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-1>;
          CachedInformationHash certificate_authorities<0..2^16-1>;
      } CertificateRequest;

Substitution syntax, choice 2 (preserving original syntax):
      CachedInformationHash Cached_authorities<1..1^16>

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

I think I prefer choice 2 as it reduce the possibility for problems when
parsing handshake messages using legacy code.

Comments suggestions?

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 19 Feb 2010 16:07:52 +0100

Martin,

> it supports caching would be a good idea.

I'm not opposing this.

Are you saying that the server (at server hello) should state which TYPE of
elements is supports for caching, or do you propose that the server should
state exactly which hash values received by the client the server accepts?

I thought you didn't want the server to be forced to choose which hash
values it accepts at server hello time.

/Stefan

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 19 Feb 2010 10:38:18 -0500

Note that the key concept described in secure_hashing.html is “secure”:  

Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010.

When a hash algorithm is used for non-security purposes, such as database bucketing (http://en.wikipedia.org/wiki/Hash_table) or cache object selection, the NIST guidance does not apply.

Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Smith
Sent: Friday, February 19, 2010 10:06 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft

"Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). " 

Regards,
Brian

---

From: Brian Smith <[email-masked]>
Date: Fri, 19 Feb 2010 09:39:55 -0600

> parameter of the CertificateRequest message.
That's why I suggested to treat a zero-length 
CertificateRequest.certificate_authorities (encoded "0x00 0x00") as "use 
the cached value" if and only if the server hello says that the server 
supports caching it. Maybe it is also possible to treat a zero-length 
Certificate.certificate_list ("0x00 0x00 0x00") as "use the cached 
value" if and only if the server hello says the server supports caching 
it. I suggested omitting the Certificate message completely only because 
I am not sure if any cipher suites allow zero-length certificate lists 
for another reason.

Regards,
Brian

---

From: Martin Rex <[email-masked]>
Date: Fri, 19 Feb 2010 17:15:15 +0100 (MET)

> values it accepts at server hello time.

With "reporting back for which elements it supports caching"
I meant "supporting in theory", not an actual match of the
real data from future handshake messages with proposed hashed
values supplied by the client.

This should be done in a fashion that the client can probe
on the initial connect (i.e. when the client does not have any
values cached) to determine:

   - whether the server supports caching of data at all
   - for which elements the server supports caching in principle
   - confirmation which hash algorithm the server supports

which the client can then use to decide:
   - whether caching of any handshake data for that server makes
     any sense at all of would be a complete waste
   - which hash algorithm to use to identify cached handshake
     data in future handshakes with that server

-Martin

---

From: Adam Langley <[email-masked]>
Date: Fri, 19 Feb 2010 11:27:58 -0500

> 2) To define a format which preserves the original handshake message syntax.

I'm afraid that I'm still not clear what you mean here.

In the current draft:

"Following a successful exchange of "cached_information" extensions,
the server may replace data objects identified through the client
extension with any of the CachedInformationHash values received from
the client, which matches the replaced object."

My understanding is that this is a "memcmp for magic values" scheme.
Given the size of the hashes, this isn't unreasonable, I just feel
that we should be more explicit if possible.

Given that, we could

1) define new handshake messages, although you're correct that the
namespace is small.

2) Redefine the structure of the existing handshake messages for the
case when this extension is in effect. The new structures would have
an explicit field for substituted hashes, in addition to the old
fields. Hosts would choice one or the other to be non-zero length.
(Based on my knowledge of NSS and OpenSSL's code, this wouldn't be too
bad to implement.)

3) Wedge the cached values into the current structures somehow. Brian
suggests using zero lengths as a magic marker. However, the hash value
would still need to follow because the client could have predicted one
of several values. I think this is a poor man's version of option two.

AGL

---

From: Brian Smith <[email-masked]>
Date: Fri, 19 Feb 2010 10:44:43 -0600

> of several values. I think this is a poor man's version of option two.
I had been making the (apparently incorrect) assumption that only one 
CachedObject per CachedInformationType value was allowed in the client 
hello. I thought the intention here was to have the client always 
cache/send the value for each information type that was most recently 
received from the server (perhaps out-of-band). Is there a need for more 
flexibility than that? AFAICT, for the uses identified so far, there isn't.

Regards,
Brian

---

From: Adam Langley <[email-masked]>
Date: Fri, 19 Feb 2010 11:52:58 -0500

On Fri, Feb 19, 2010 at 11:44 AM, Brian Smith <[email-masked]> wrote:
> hello. I thought the intention here was to have the client always cache/send
> the value for each information type that was most recently received from the
> server (perhaps out-of-band). Is there a need for more flexibility than
> that? AFAICT, for the uses identified so far, there isn't.

I had interpreted the draft to mean that multiple possible
CachedObjects with the same type could be presented.

I can imagine some use cases where this would be helpful: an
organisation which can multiple serving clusters for the same domain
name, where each cluster has a different certificate. Or when a new
certificate was being rolled out to a number of servers, but clients
were getting load balanced between them.

However, given that this is only an optimisation, these cases might be
sufficiently unimportant that we can forbid multiple CachedObjects
with the same type and reap the benefits in a simpler substitution
scheme. I think I would be happy with that unless some particularly
compelling use case arises.

AGL

---

From: Brian Smith <[email-masked]>
Date: Fri, 19 Feb 2010 11:05:21 -0600

Kemp, David P. wrote:
>
> Note that the key concept described in _secure_hashing.html_ is “secure”:
>
> /Federal agencies should stop using SHA-1 for digital signatures, 
> digital time stamping and other applications that require collision 
> resistance as soon as practical, and must use the SHA-2 family of hash 
> functions for these applications after 2010./
>
> / /
>
> When a hash algorithm is used for non-security purposes, such as 
> database bucketing (http://en.wikipedia.org/wiki/Hash_table) or cache 
> object selection, the NIST guidance does not apply.
>
Yes, I read that sentence too. And, I agree with your very common-sense 
interpretation of things. But, while the sentence you quote has the 
qualifier "that require collision resistance," the rest of the 
recommendations against SHA-1 don't have that qualifier, so I am not 
totally convinced. And, I am definitely not convinced that all 
users/customers will be convinced, so I would rather be safe than sorry.

Perhaps this all can be avoided by simply not having the client 
calculate hashes at all for . For example, would this work?:

struct {
     opaque token<0..255>;
} CachedObject;

In a server hello: If CachedObject.token is empty, then the client must 
use its cached value for the given information type. The corresponding 
fields in the server hello (e.g. Certificate.certificate_list or 
CertificateRequest.certificate_authorities) MUST be empty. If 
CachedObject.token is not empty, then the server will send a new value, 
and that new value can be identified by the client in subsequent client 
hellos using the given token; an empty value (e.g. an empty 
Certificate.certificate_authorities) must not be interpreted as an 
indication to use a previously-cached value. For a given value, a server 
should return the same token string to every client, so that the token 
isn't used as a tracking cookie that could be used to distinguish 
distinct clients. The server must ensure that the same token is never 
used to identify different values (that is, every token must map to at 
most one value). Since the goal of this extension is to reduce the 
number of bytes transmitted, the token should be short. It is strongly 
recommended that the server use a secure hash algorithm (e.g. SHA-2) of 
the value as the token.

In a client hello: CachedObject.token must not be empty, and it must 
contain a token previously retrieved from the same server (either in a 
previous TLS handshake, or out of band).

Regards,
Brian

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 19 Feb 2010 18:05:14 +0100

I had the same type if use case in mind.

I think it is better and rather harmless to allow the flexibility.
Client provide a list.... Server picks one. That is an old, well tested and
useful concept.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 19 Feb 2010 18:17:39 +0100

Brian,  

The use of hash functions in this draft does not require collision
resistance.
This is actually quite easy to prove.

/Stefan

On 10-02-19 6:05 PM, "Brian Smith" <[email-masked]> wrote:

> Kemp, David P. wrote:
>>     
>>  
>> 
>> Note that the key concept described in secure_hashing.html is ³secure²: 
>>  
>>  
>>  
>> Federal agencies should stop using SHA-1 for digital signatures, digital time
>> stamping and other applications that require collision resistance as soon as
>> practical, and must use the SHA-2 family of hash functions for these
>> applications after 2010.
>>  
>>  
>>  
>> When a hash algorithm is used for non-security purposes, such as database
>> bucketing (http://en.wikipedia.org/wiki/Hash_table) or cache object
>> selection, the NIST guidance does not apply.
>>  
> interpretation of things. But, while the sentence you quote has the qualifier
> "that require collision resistance," the rest of the recommendations against
> SHA-1 don't have that qualifier, so I am not totally convinced. And, I am
> definitely not convinced that all users/customers will be convinced, so I
> would rather be safe than sorry.
> 
> Perhaps this all can be avoided by simply not having the client calculate
> hashes at all for . For example, would this work?:
> 
> struct {
> In a server hello: If CachedObject.token is empty, then the client must use
> its cached value for the given information type. The corresponding fields in
> the server hello (e.g. Certificate.certificate_list or
> CachedObject.token is not empty, then the server will send a new value, and
> that new value can be identified by the client in subsequent client hellos
> using the given token; an empty value (e.g. an empty
> Certificate.certificate_authorities) must not be interpreted as an indication
> to use a previously-cached value. For a given value, a server should return
> the same token string to every client, so that the token isn't used as a
> tracking cookie that could be used to distinguish distinct clients. The server
> must ensure that the same token is never used to identify different values
> (that is, every token must map to at most one value). Since the goal of this
> extension is to reduce the number of bytes transmitted, the token should be
> short. It is strongly recommended that the server use a secure hash algorithm
> (e.g. SHA-2) of the value as the token.
> 
> In a client hello: CachedObject.token must not be empty, and it must contain a
> token previously retrieved from the same server (either in a previous TLS
> handshake, or out of band).
> 
> Regards,
> Brian
> 
> 
>

---

From: Martin Rex <[email-masked]>
Date: Fri, 19 Feb 2010 18:45:26 +0100 (MET)

>      CachedInformationType type;

I've been advocating the use of a hash value over the real data
so that the handshake will do the right thing automatically if
the data cached by the client and the data the server is going
to return no longer match: the server is going to send the new
data in full, and the client can update his cache.

You definitely do not want a handshake failure (which always
requires application involvement to recover from and a 
new connection) if the data cached by the client is out of
sync with what the server wants to return.

The client needs to be able to distinguish omitted handshake
data (which he has cached) from new real data, and the
server should not be forced to precompute all handshake
messages when composing the server hello handshake message
in order to confirm matches to the data that the client
has indicated to have cached.

-Martin

---

From: Brian Smith <[email-masked]>
Date: Fri, 19 Feb 2010 11:52:47 -0600

> This is actually quite easy to prove.
Nobody is questioning that at all.

My points are:

1. As long as this web page on the NIST website says, basically, "don't 
use SHA-1 for anything," people will want to disable SHA-1 whenever they 
can. It doesn't matter that this page on the website isn't the official 
NIST recommendation on the matter. It doesn't matter that NIST 
recommendations are only binding for federal government work. It doesn't 
matter that the official NIST recommendation (SP 800-107) is more 
limited in its recommendations against SHA-1. People will still want to 
disable it. Like I said many messages before, even if it isn't a  
technical problem, it is a social problem. And, that problem can be 
easily avoided.

2. It doesn't make sense to require SHA-1 support to be added to 
implementations that don't need SHA-1 for any other purpose. TLS 1.2 
doesn't require SHA-1 for anything, so you can build a compliant and 
useful implementation without SHA-1 support. There are technical 
advantages to doing so. Obviously, this isn't practical for 
general-purpose web browsers, but it is practical for many other uses.

3. There are two simple alternatives that work: (a) mandate SHA2 instead 
of SHA1, at least for TLS 1.2+, or (b) avoid mandating any hashing at 
all by using opaque tokens.

Cheers,
Brian

---

From: Martin Rex <[email-masked]>
Date: Fri, 19 Feb 2010 18:58:59 +0100 (MET)

> support mandatory only if/when the connection's negotiated version is 

Another issue that you may not have realized is what the requirement
to support SHA-1 really means.  

http://tools.ietf.org/html/rfc3365#section-7

The requirement for SHA-1 is for the purpose of interoperability,
and it makes perfect sense to require SHA-1 to be present in
implementations so that this can be implemented for all existing
protocol stacks, including those prior to TLSv1.2.

Adding a "RECOMMENDED to support SHA-256" to the document wouldn't hurt.

The question which algorithm consumers of this technology
will use (and which algorithms they reject) is a seperate
question.

The protocol version {0x03,0x00}, {0x03,0x01} and {0x03,0x02}
are going to be around for quite some years to come.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 19 Feb 2010 12:59:20 -0500

As Stefan pointed out, MUST support does not equal MUST use.  If you or your customers cannot be convinced that the NIST guidance is irrelevant to cache item tagging, then your implementation can certainly support SHA-2.  It is even “legal” (in an RFC 2119 sense) for your customers to configure your application to refuse to use SHA-1 if they believe that is necessary to comply with NIST guidance, as long as other customers (guided by appropriate documentation and common sense) are able to configure it to use SHA-1.

I oppose removing a requirement to MUST support a common algorithm.   And I would oppose making the common algorithm SHA-2 because that is moving in the wrong direction for saving bytes:  a single uint32 is sufficient; more (SHA-1) is excessive, and much more (SHA-2) is much more excessive.   This applies equally whether the server pre-calculates an opaque token and sends it to the client or the client and server each calculate the token interoperably.

Dave

From: Brian Smith [mailto:[email-masked]] 
Sent: Friday, February 19, 2010 12:05 PM

And, I am definitely not convinced that all users/customers will be convinced, so I would rather be safe than sorry.

Perhaps this all can be avoided by simply not having the client calculate hashes at all.

…

It is strongly recommended that the server use a secure hash algorithm (e.g. SHA-2) of the value as the token.

---

From: Martin Rex <[email-masked]>
Date: Fri, 19 Feb 2010 19:21:35 +0100 (MET)

> technical problem, it is a social problem. And, that problem can be 

There is some confusion about what problems there are with SHA-1.

But doing as you suggest, you are just adding massively to that
confusion, depicting SHA-1 as being universally bad.

My memory was, that NIST's recommendation was to no longer
issue certs with sha-1 as a signature algorithm after 2010.

I don't know what you mean by "disabling SHA-1", but most software
is likely to not have such a configuration settings -- and those
software that does is likely to no longer interoperate securely
with others if SHA-1 would be universally disabled.

What you are asking for is a policy like this:

"We can no longer let you use HTTPS because it makes use of
 TLSv1.0 with contains the universally insecure SHA-1 algorithm.
 Please use HTTP URLs instead." 

> general-purpose web browsers, but it is practical for many other uses.

You are mistaken.  SHA-1 is a MUST implement for TLSv1.2.

TLS uses a SHA-256 only PRF and provides cipher suites with SHA-256,
but limiting an implmentation to that subset of TLSv1.2 is only
an option for the consumer of the technology, not an option
for the implementor.

Limiting your application to allow only protocol version TLSv1.2
and only ciphersuites with SHA-256 hash and support of Certs
with signature algorithms using sha-256 is going to make your
application non-interoperable with 99,8% of the installed base
of TLS-enables apps.  And that situation is going to change
only at a fairly slow pace in the future.

So it could be that the particular isolated environment that
you are looking at might be happy with such a configuration,
but for the average consumer of this technology it just would not
make any sense. 

And mind you, for your isolated environment, you can certainly
implement and use the caching extension with SHA-256 only,
the proposal has the necessary protocol options.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 19 Feb 2010 19:23:39 +0100

> Adding a "RECOMMENDED to support SHA-256" to the document wouldn't hurt.

I could add this.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 19 Feb 2010 19:28:13 +0100

Added Tim Polk,

As we are so fortunate that we have a security AD working for NIST maybe Tim
could help us clarify NIST intention.

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Fri, 19 Feb 2010 19:28:40 +0100 (MET)

> > Adding a "RECOMMENDED to support SHA-256" to the document wouldn't hurt.

I would like to correct myself, I'd rather use a MAY. (=true option).

A "RECOMMENDation" should come with an explanation/rationale of the
purpose.  We currently do not see a technical purpose to _not_ use
SHA-1 only a sure waste of network bandwith, CPU cycles and
cache memory consumption.

The only purpose would be to allow explicit non-techies with universal
paranoia and braindead policies to disable it.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 19 Feb 2010 10:36:38 -0800

Brian Smith wrote:
> .... Note that this is how RFC50[77] works (you 

While that method works, an easier method is for the client to include a
non-empty session ID in its ClientHello when attempting to resume a session
based on a session ticket.  If the server does resume the session, then it
returns the client-generated session ID.  From RFC 5077:

    When presenting a ticket, the client MAY generate and include a
    Session ID in the TLS ClientHello.  If the server accepts the ticket
    and the Session ID is not empty, then it MUST respond with the same
    Session ID present in the ClientHello.  This allows the client to
    easily differentiate when the server is resuming a session from when
    it is falling back to a full handshake.  Since the client generates a
    Session ID, the server MUST NOT rely upon the Session ID having a
    particular value when validating the ticket.  If a ticket is
    presented by the client, the server MUST NOT attempt to use the
    Session ID in the ClientHello for stateful session resumption.
    Alternatively, the client MAY include an empty Session ID in the
    ClientHello.  In this case, the client ignores the Session ID sent in
    the ServerHello and determines if the server is resuming a session by
    the subsequent handshake messages.

Mike

---

From: Adam Langley <[email-masked]>
Date: Fri, 19 Feb 2010 14:47:06 -0500

> Client provide a list.... Server picks one. That is an old, well tested and

So you're suggesting option (2): that we redefine the structure of the
existing messages to include a place for the hash? I'm fine with that.

AGL

---

From: Wan-Teh Chang <[email-masked]>
Date: Fri, 19 Feb 2010 13:48:51 -0800

>          CachedCertList certificate_list<0..2^24-1>;

In choice 2, did you mean CachedCertList or CachedCert?
With CachedCertList, the Certificate message would contain
a list of lists of certificates.

In choice 2, how does a decoder distinguish between 'opaque' and
CachedInformationHash?  Is it supposed to "sniff" the first few
bytes to see whether it looks like an ASN.1 DER encoded cert?

Wan-Teh

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 20 Feb 2010 01:45:42 +0100

> In choice 2, did you mean CachedCertList or CachedCert?

It's CachedCertList in the sense that it contains a hash of a
certificate_list vector.

> a list of lists of certificates.
It would use the same structure as the original handshake message. That is,
a 3 byte total length followed by a number of 3byte length vectors.

The only difference is that in the original syntax the inner vectors are
opaque and in the substitution syntax they have the structure of a
CachedInformationHash.

> bytes to see whether it looks like an ASN.1 DER encoded cert?

The client is supposed to compare the content against the
CachedInformationHash values sent to the server in the Client Hello
extension. If both length and content matches a value sent to the server,
there is a match.

/Stefan

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 22 Feb 2010 09:35:26 +0100

Brian Smith <[email-masked]> writes:

> 1. As long as this web page on the NIST website says, basically,
> "don't use SHA-1 for anything," people will want to disable SHA-1
> whenever they can. It doesn't matter that this page on the website
> isn't the official NIST recommendation on the matter.

I'd like to suggest another argument to support your reasoning: some
FIPS approved crypto libraries no longer export MD5.  I expect the same
to be true for SHA-1 within a few years.  This means that SHA-1 will no
longer be as easily available, for these non-crypto purposes needed in
tls-cached-info.

We noticed this in GnuTLS, that needs MD5 for older TLS versions.  Our
"solution" was to add an optional MD5 implementation to GnuTLS, rather
than always depending on the crypto library for MD5.  This felt strange
to do, but is the logical consequence of deprecating MD5, and eventually
SHA-1, as supported algorithms.

Chosing SHA-256 will give us more time, but we'll likely run into the
same issue eventually anyway.  I believe this suggests that algorithm
agility is useful whenever any crypto-related algorithm is _used_, even
if it is used for non-crypto related purposes.

/Simon

---

From: Martin Rex <[email-masked]>
Date: Mon, 22 Feb 2010 16:41:28 +0100 (MET)

> longer be as easily available, for these non-crypto purposes needed in

I do not agree to this conclusion.  IIRC, NIST never liked MD5 from
the beginning, and it was always clear about that, which is why
SHA-1 as an alternative became ubiquitous available everywhere where
a secure hash algorithm was needed.

While it seems sensible to deprecate SHA-1 for use in digital
signatures, it is still present in many certs and many signatures.
Even last year, some PKIs have been newly set up with a hierarchy
of CAs using SHA-1 for the signature on the intermediate CA and
end entity certs--probably because the SHA-2 algorithm is not
yet universally available in implementations.

If you look at the mandatory-to-implement algorithm for SSLv3 and
TLS up to v1.2 (rfc5246):

  TLSv1.0 (rfc-2246, section 9)  TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  TLSv1.1 (rfc-4346, section 9)  TLS_RSA_WITH_3DES_EDE_CBC_SHA
  TLSv1.2 (rfc-5246, section 9)  TLS_RSA_WITH_AES_128_CBC_SHA
  
So getting rid of SHA-1 will require a significantly larger effort
than getting rid of MD5 (-based signatures).

> if it is used for non-crypto related purposes.

TLS truncates the PRF output to 12 octets for the finished message.
Maybe we should truncate the hash for the caching extension to
20 octets (which means that sha-1 hash values are sent in full)?

-Martin

---

From: Brian Smith <[email-masked]>
Date: Tue, 23 Feb 2010 10:52:39 -0600

> a secure hash algorithm was needed.
In the short term, Martin is right. Even with the new recommendations, 
crypto modules will still be able to be FIPS-certified even if they 
contain a SHA-1 implementation, as long because SHA-1 still has approved 
uses (HMAC-SHA1 in particular). However, I'm not sure that will be the 
case 10 years from now. I think it would be better for this extension to 
be specified in a way that doesn't require it to be periodically updated 
in order to be implementable using only primitives provided by certified 
crypto modules.

> yet universally available in implementations.
It depends on the application. In 2011, SHA-1 certificates will no 
longer be acceptable for many uses within the US government. And, that 
is already the case now in 2010 with the German government, AFAICT.

> than getting rid of MD5 (-based signatures).
The spec says that those algorithms are required unless the profile of 
TLS in use specifies otherwise. The NSA Suite B Profile for TLS (RFC 
5430) defines a profile that doesn't use SHA-1 at all. 
(http://tools.ietf.org/html/rfc5430#section-3).

> 20 octets (which means that sha-1 hash values are sent in full)?
That sounds reasonable to me, but I'd also require the SHA-1 hashes 
truncated too, because (a) SHA-1 is overkill too (as David Kemp pointed 
out), and (b) it would be impossible for an implementer to miss the 
truncation requirement, evein in a SHA-1-only implementation.

Regards,
Brian

---

From: Brian Smith <[email-masked]>
Date: Tue, 23 Feb 2010 11:19:52 -0600

> sync with what the server wants to return.
This already happens with session resumption, when the server re-uses a 
session ID (so that the client's mapping of session ID -> session state 
doesn't match the server's mapping of session ID -> session state). The 
solution there was basically to tell the server "don't do that," and I 
think the same solution can be used here. That is why I suggested 
recommending the server to use a SHA-2 hash of the cached data.

> data (which he has cached) from new real data
I believe my proposed scheme already does this. If the client cached a 
zero-length string, he will have a non-zero-length token for it. If the 
server wants to send a new non-zero-length value for that cached item, 
then it would either send no token at all for that item (indicating that 
the new value can't be cached) or it would send a new token.
> and the server should not be forced to precompute all handshake
The items that are useful to be cached are all sent directly after the 
server hello (certificate, certificate request, and key exchange). 
There's nothing else that's large in the handshake. And, in practice, 
the server has to do this anyway if it supports session resumption. 
Regardless, it isn't a burden for the server anyway. Every time the 
server sends a new cachable item, it would calculate the token and cache it.

Regardless of the SHA1 issue, if the extension can be designed so that 
the client doesn't have to do any calculations in order to use the 
extension, that is a big win, because it makes the client much easier to 
implement and much simpler to maintain. It is much easier to perform 
maintenance on servers than on clients, especially clients that have 
their TLS implementation baked into firmware of consumer devices.

Cheers,
Brian

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 24 Feb 2010 18:00:47 +0100

Would it help to make everyone happy if we said that implementers SHOULD
support SHA-1?

/Stefan

On 10-02-23 5:52 PM, "Brian Smith" <[email-masked]> wrote:

> In the short term, Martin is right. Even with the new recommendations, crypto
> modules will still be able to be FIPS-certified even if they contain a SHA-1
> implementation, as long because SHA-1 still has approved uses (HMAC-SHA1 in
> particular). However, I'm not sure that will be the case 10 years from now. I
> think it would be better for this extension to be specified in a way that
> doesn't require it to be periodically updated in order to be implementable
> using only primitives provided by certified crypto modules.
> 
>>  
> It depends on the application. In 2011, SHA-1 certificates will no longer be
> acceptable for many uses within the US government. And, that is already the
> case now in 2010 with the German government, AFAICT.
> 
>>  
> The spec says that those algorithms are required unless the profile of TLS in
> use specifies otherwise. The NSA Suite B Profile for TLS (RFC 5430) defines a
> profile that doesn't use SHA-1 at all.
> That sounds reasonable to me, but I'd also require the SHA-1 hashes truncated
> too, because (a) SHA-1 is overkill too (as David Kemp pointed out), and (b) it
> would be impossible for an implementer to miss the truncation requirement,
> evein in a SHA-1-only implementation.
> 
> Regards,
> Brian
> 
>

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 24 Feb 2010 12:53:05 -0500

I'd be happier with MUST.  I don't buy the argument that all code that
makes up an application must come from a certified crypto library;
certainly XML parsers, GUI toolkits, and a million other things are
available to developers, and I find it hard to believe that 20 years
from now nobody will be able to find some C code somewhere to do SHA-1.
If it is impossible to get consensus without a SHOULD, then so be it,
but that is a cop-out.

I agree with Martin and Brian that all hashes including SHA-1 should be
truncated.  To make it impossible for developers to miss (and to save a
few bits of bandwidth) it should be truncated to less than 20 octets.
I'd suggest 8 octets, but pick your favorite number (8, 12, 16) less
than 20.

      struct {

           HashAlgorithm hash;

           opaque hash_value<8>;      // was hash_value<1..255>;

      } CachedInformationHash;

Dave

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, February 24, 2010 12:01 PM
To: Brian Smith; [email-masked]
Cc: Simon Josefsson; Kemp, David P.; [email-masked]
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track"
draft

/Stefan

Martin Rex wrote: 

Simon Josefsson wrote:

  

Regards,
Brian

  _____

---

From: Marsh Ray <[email-masked]>
Date: Wed, 24 Feb 2010 12:25:29 -0600

Kemp, David P. wrote:
> I’d be happier with MUST.  I don’t buy the argument that all code that

The problem with specifying SHA-1 is that it's a recognized as a crypto
algorithm. It's showing its age and various parties are starting to
forbid its use.

It will not be so fun to convince reviewers that "yes we're using SHA-1
but not in a way that really matters."

> I’d suggest 8 octets, but pick your favorite number (8, 12, 16) less
> than 20.

If all you need is a 64-bit checksum for data-structure-style hashing
and indexing, use any old old-fashioned checksum algorithm.

This would be simple for everyone to implement and it clearly
communicates your design intent (that the security of the design does
not depend on any properties of this value's calculation).

Using a weakened form of a partially-broken and deprecated cryptographic
algorithm seems like it could provoke a lot of useless discussion.

- Marsh

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 24 Feb 2010 14:50:36 -0500

Marsh Ray wrote:
> It will not be so fun to convince reviewers that "yes we're using
> SHA-1 but not in a way that really matters."
>
> If all you need is a 64-bit checksum for data-structure-style
> hashing and indexing, use any old old-fashioned checksum algorithm.
>
> communicates your design intent (that the security of the design
> does not depend on any properties of this value's calculation).

+1 in principle.

But practically speaking, do you have any suggestions for well-known non-cryptographic hash algorithms?  A quick IANA search turned up Kerberos checksums http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml, including CRC32 (4 octets), des-mac-k (8 octets), and several 16 octet algorithms including MD4 and MD5.

A search for other "hash", "mac", or "checksum" registries turned up nothing new.

It doesn't feel quite right to add a non-cryptographic checksum to the RFC 5246 registry:

      enum {
          none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
          sha512(6), (255)
      } HashAlgorithm;

so even if there were such an algorithm, permitting both it and cryptographic hashes would be painful.

I don't see an alternative that satisfies both "simple to implement" and "clearly communicates intent".  My care-abouts are 1) a common interoperable algorithm and 2) bandwidth.  Computation speed is unimportant, so if everyone thinks sha256 will be cryptographically viable for the foreseeable future and SHA-1 will soon be impossible to get "approved", then sha256 truncated to 64 bits could be a reasonable MUST-support algorithm.

Dave

---

From: Marsh Ray <[email-masked]>
Date: Wed, 24 Feb 2010 15:02:55 -0600

Kemp, David P. wrote:
> But practically speaking, do you have any suggestions for well-known
> non-cryptographic hash algorithms?

Hmm, starting with http://en.wikipedia.org/wiki/List_of_hash_functions

FNV seems like a good candidate.
http://en.wikipedia.org/wiki/Fowler-Noll-Vo_hash_function

Pros:
* Wide existing usage:
http://www.isthe.com/chongo/tech/comp/fnv/index.html#history

* On that page they disclaim patents on it.

* It is defined in power-of-two sizes from 32 to 1024 bits.

* Something of an endorsement:
"We experimetned with several different hash functions and found FNV has
to be the best one."
http://domino.watson.ibm.com/library/cyberdig.nsf/papers/2314E66547EF9CC5852576BE005F1E4F/$File/rc24939.pdf

Cons:

* Uses multiply. Probably not a big deal in practice.

* Not (yet) referenceable in a formal standards doc.

> A quick IANA search turned up
> Kerberos checksums
> http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml,
> including CRC32 (4 octets), des-mac-k (8 octets), and several 16
> octet algorithms including MD4 and MD5.

CRC64 doesn't seem to be so great with collisions:
http://www.cs.ucl.ac.uk/staff/d.jones/crcnote.pdf
The authors propose a better version.

You could use a pair of (some variant of) CRC32, each preloaded with
different values. This may not be any better than CRC64 though and may
not be terribly efficient.

> enum { none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), 
> sha512(6), (255) } HashAlgorithm;
> 

Is it really necessary for this to be a flexible parameter?

A implementation now has a choice: implement them all (including ones
that are never used in practice), or risk not not being compatible
somewhere.

> I don't see an alternative that satisfies both "simple to implement"
> and "clearly communicates intent".  My care-abouts are 1) a common
> interoperable algorithm and 2) bandwidth.  Computation speed is
> unimportant,

There's always code size to consider.

> so if everyone thinks sha256 will be cryptographically
> viable for the foreseeable future and SHA-1 will soon be impossible
> to get "approved", then sha256 truncated to 64 bits could be a
> reasonable MUST-support algorithm.

Now you'll have to explain why you're taking the output of an
industrial-strength hash function and throwing away 3/4 of it. :-) Plus,
it's wasted effort since collisions will be possible to find in any
64-bit hash function.

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Thu, 25 Feb 2010 08:06:23 +0200

Something like this algorithm also has the benefit of side-stepping the whole national algorithms issue.

While "American" crypto algorithms may be unacceptable in Russia, perhaps an "American" non-crypto algorithms would be acceptable, and we won't need a GOST version.

(or Camelia)

On Feb 24, 2010, at 11:02 PM, Marsh Ray wrote:

> Scanned by Check Point Total Security Gateway.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 25 Feb 2010 14:27:39 +0100

I think this issue is blown totally out of any reasonable proportions.

This is not the first time a hash is used to provide an identifier where no
strong collision resistance is required. I don't want to break my back to
avoid using a perfectly suitable hash algorithm just for political reasons.

/Stefan

On 10-02-25 7:06 AM, "Yoav Nir" <[email-masked]> wrote:

> While "American" crypto algorithms may be unacceptable in Russia, perhaps an
> "American" non-crypto algorithms would be acceptable, and we won't need a GOST
> version.
> 
> (or Camelia)
>

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 25 Feb 2010 15:46:28 +0100

> avoid using a perfectly suitable hash algorithm just for political reasons.

I agree that the political reasons shouldn't be a serious concern here.

There is still the technical concern that at some point in the future
SHA-1 may no longer be easily available in libraries and we want to
transition to some other algorithm.  Algorithm agility is useful even
for non-crypto algorithms.

Here is a proposal: Say SHA-1 is a MUST when TLS < 1.2 is negotiated but
later TLS versions MUST use the same hash as the one used by the PRF?

Btw, is the intention that cached info can be used with TLS versions <
1.2?  If it is only for TLS >= 1.2, then SHA-256 seems to make more
sense than SHA-1 because TLS 1.2 uses SHA-256.

/Simon

---

From: Brian Smith <[email-masked]>
Date: Thu, 25 Feb 2010 10:56:07 -0600

Simon Josefsson wrote:
>
> Here is a proposal: Say SHA-1 is a MUST when TLS<  1.2 is negotiated but
This is what I was originally going to suggest. The problem is that the 
client doesn't necessarily know which PRF will be used until it receives 
the ServerHello because the server could be TLS 1.0/1.1-only, because 
the PRF depends on the ciphersuite chosen by the server, and because the 
PRF for the chosen ciphersuite might not be based on a HMAC.

My first suggestion, a long time ago, was to just use the fingerprint of 
the end certificate as the key for certificate caching. This is 
something that both sides already have to calculate anyway. In fact, 
many implementations are already using the certificate fingerprint as a 
cache key for internal purposes. Then, have the client and server use 
the Client Certificate URL extension if they want to optimize the client 
certificate part, which potentially saves many many more bytes than the 
caching CertificateRequest.certificate_authorities would. Just give up 
defining a generic mechanism; the level of generality and complexity in 
the current draft is really unwarranted.

My second suggestion is to have the server calculate the hash, and give 
the calculated hash to the client along with the content. Then the 
client and the server don't have to agree on any algorithms at all, and 
the server can choose whatever algorithm it wants. If you leave the hash 
identifier in there then the client could potentially double-check the 
server's calculation--something which I think is wasteful, but I think 
it is wasteful to require both sides to calculate the hashes too, 
especially given the extra client-side complexity that it causes.

Regards,
Brian

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 25 Feb 2010 17:47:40 +0100

Simon,

Note that the requirement is MUST support, it is not MUST use.
It is perfectly allowed to use SHA-256.

Does that solve your concern?

---

From: Brian Smith <[email-masked]>
Date: Thu, 25 Feb 2010 11:09:35 -0600

> Does that solve your concern?
This doesn't make sense. If the server doesn't implement SHA-1, then a 
client that only sends SHA-1 to it won't be able to use the extension 
effectively. If the client cannot rely on SHA-1 working then what is the 
value of the "MUST" requirement? Similarly, if the client doesn't 
implement SHA-1, but the server only supports SHA-1, then they won't be 
able to take advantage of the optimization.

- Brian

---

From: Martin Rex <[email-masked]>
Date: Thu, 25 Feb 2010 21:11:39 +0100 (MET)

> it's wasted effort since collisions will be possible to find in any

The original purpose of this extension/proposal is to save network
bandwith on repeated _full_ TLS handshakes between peers and
where TLS session caching is not available for whatever reason.

In order to make clear that collision resistance of SHA-1 is
perfectly sufficient, I think the hash value should be
unconditionally truncated to, say, 128-bit (16 octets),
independent of which hash algorithm is used.  This would
also answer any question about whether SHA-1 is sufficient. It is.

Btw. the certificate fingerprinting and public key fingerprinting
algorithms currently also still use SHA-1 (e.g. rfc-5280 4.2.1.2).

I firmly believe that "MUST support SHA-1" is perfectly fine for
this proposal and more than just "good enough" to ship it, provided
that both peers can reliably determine (negotiate) through the
Hello extension whether they support or prefer a newer/different
common hash algorithm before the client starts populating his cache.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 25 Feb 2010 20:29:25 +0100

Brian,

On 10-02-25 6:09 PM, "Brian Smith" <[email-masked]> wrote:

> value of the "MUST" requirement?

MUST support means that the client can rely on that SHA-1 is working.

> Similarly, if the client doesn't

It just means that the server won't accept caching this time around. It's
not like the end of the world. The client can try multiple hashes next time
to figure out what the server really accepts.

/Stefan

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 26 Feb 2010 10:22:29 +0100

> Does that solve your concern?

My concern is to get algorithm agility working here, and that involves
some form of negotiation.  Either explicitly in the protocol or
implicitly through normative statements in the document.

Saying 'you MUST support SHA-1 and MAY use SHA-256' without explaining
how the choice is negotiated would not solve my concern -- if that
wording is the only alternative to hard-coding SHA-1, I would actually
prefer the latter.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 26 Feb 2010 10:38:16 +0100

Brian Smith <[email-masked]> writes:

> This is what I was originally going to suggest. The problem is that
> the client doesn't necessarily know which PRF will be used until it
> receives the ServerHello because the server could be TLS 1.0/1.1-only,
> because the PRF depends on the ciphersuite chosen by the server, and
> because the PRF for the chosen ciphersuite might not be based on a
> HMAC.

Ouch.  Maybe we could do it on the TLS protocol version advertised by
the client then?  We'd get agility, but slower transition since older
versions are still advertised.  Thus, clients still advertising at
minimum TLS v1.0 or v1.1 would MUST support/use SHA-1, clients at
minimum advertising TLS v1.2 would MUST support/use SHA-256.  I'm not
sure what to do say about future versions though.  Can we say "use the
default PRF algorithm"?

> My first suggestion, a long time ago, was to just use the fingerprint
> of the end certificate as the key for certificate caching. This is
> many implementations are already using the certificate fingerprint as
> a cache key for internal purposes. Then, have the client and server
> use the Client Certificate URL extension if they want to optimize the
> client certificate part, which potentially saves many many more bytes
> than the caching CertificateRequest.certificate_authorities
> would. Just give up defining a generic mechanism; the level of
> generality and complexity in the current draft is really unwarranted.

I don't think the X.509 certificate is a good idea here -- TLS can be
used without X.509 certificates.

> My second suggestion is to have the server calculate the hash, and
> give the calculated hash to the client along with the content. Then
> the client and the server don't have to agree on any algorithms at
> all, and the server can choose whatever algorithm it wants.

I like this approach.  The server gets to chose the hash, and the client
will have to comply.  It is easy to implement, and it is possible to
transition to other checksum algorithms over time.

One improvement may be for the client to send a list of hashes it
supports, though, and the server picking the best subset of it, as long
as it is compatible with what it supports?

/Simon

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 26 Feb 2010 13:05:57 +0100

Simon,

I have to admit that it bothers me that this to me is so much a non problem
and that you and others insist that it is a problem.

IETF have tons of RFCs where the implementer can choose an arbitrary format
or type of value (like cipher suite, signature algorithm, etc). It is
perfectly understood that not everyone will implement every possible format
or value type, so RFCs often list one or a few formats or types that
implementers must support. If you want to be sure to interoperate, then
choose one of the mandatory to support options.

If you have a reason to use another value, then use that.

The negotiation mechanism is classic. The client provides a number of
alternative variants it can produce and the server chooses the one it
prefers. The client is free to remember this. This is already possible
through the current draft.

I can agree that it would be wise to include (as suggested by Martin) a way
for the server to indicate already in server hello which of the hash types
offered by the client that server prefers. I don't think it is necessary,
but if it can be done without too much problems, I will not object.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 26 Feb 2010 13:11:13 +0100

Simon and Brian,

> transition to other checksum algorithms over time.

I'm sorry, but this seems like a really bad idea.

The idea of this draft is that a client should be able to cash information
form a perfectly normal handshake (one where the server does not provide a
hash that may represent what it sends).

/Stefan

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 28 Feb 2010 21:47:31 -0800

Hi Stefan,

What is the disadvantage if the client cannot cache information from a
handshake in which the server does not include the hash?  

Thanks,

Joe

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stefan Santesson
> Sent: Friday, February 26, 2010 4:11 AM
> To: Simon Josefsson; Brian Smith
> Cc: [email-masked]
draft