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

From: Stefan Santesson <[email-masked]>
Date: Mon, 01 Mar 2010 10:57:47 +0100

It seems like an unnecessary complexity.

The original approach have two functions
1) Client informs the server what information it has cached
2) Server accepts caching and replaces the data with the hash provided by
the client

In the alternative approach this is expanded to:
1) The client tells server that it wants to cache data
2) The server provides hashes/identifiers of info the client may cache
3) The client signals that it has cached info with identifiers provided by
the server
4) The server replaces cached data

I see no reason to make the protocol any more complex than it need to be.

/Stefan

On 10-03-01 6:47 AM, "Joseph Salowey (jsalowey)" <[email-masked]> wrote:

> 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
> 
>> -----Original Message-----
>> 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]
>> Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track"
> draft
>> 
>> Simon and Brian,
>> 
>> On 10-02-26 10:38 AM, "Simon Josefsson" <[email-masked]> wrote:
>> 
>>>> 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.
>> 
>> 
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tls

---

From: Brian Smith <[email-masked]>
Date: Mon, 01 Mar 2010 08:29:12 -0600

> I see no reason to make the protocol any more complex than it need to be.
In the alternative approach, there is no need to pass multiple hashes of 
the same item back/forth, so the syntax becomes simpler. Also, the 
client and server do not have to agree on a hash algorithm at all, which 
is a big simplification. The client doesn't have to calculate anything, 
which is a further simplification.

Many clients won't want to cache this information unless the server says 
that it supports the extension. That is why Adam Langley and others have 
asked for a ServerHello extension that indicates the items for which the 
server supports caching. It is very easy for the server to just stuff 
the identifiers inside that extension.

Regards,
Brian

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 2 Mar 2010 09:30:38 -0800

It looks to me that the client-side hash computation option is simpler if we don't try to build in agility and negotiation.  If we feel we need these then having the server assign an identity for these values seems simpler. 

Joe

> From: Brian Smith [mailto:[email-masked]]
> Sent: Monday, March 01, 2010 6:29 AM
> To: Stefan Santesson
> Cc: Joseph Salowey (jsalowey); Simon Josefsson; [email-masked]
> Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
> 
> Stefan Santesson wrote:

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 02 Mar 2010 22:53:59 +0100

It seems that we have some decisions to make here. Hopefully we can sort
them out in Anaheim and then move on to closure.

/Stefan

On 10-03-02 6:30 PM, "Joseph Salowey (jsalowey)" <[email-masked]> wrote:

> It looks to me that the client-side hash computation option is simpler if we
> don't try to build in agility and negotiation.  If we feel we need these then
> having the server assign an identity for these values seems simpler.
> 
> Joe
>

---

From: Marsh Ray <[email-masked]>
Date: Tue, 02 Mar 2010 16:34:56 -0600

IT'S 64 BITS PEOPLE!!!

64 nearly-arbitrary bits.

As I understand it, here are the requirements for these bits:

    1. Be reproducible given the same source data

    2. Not collide too much on typical objects, most of which have at
       least some strong random content.

    3. Not introduce interop problems with a one-shot negotiation

    4. Not be a pain to implementers (external libraries,
       deprecated crypto)

    5. Not be a pain to users

Ya don't have to meet at some hotel to work out a protocol for how to
negotiate the truncated cryptographic hash function that is used to pick
these bits.

Check this out for inspiration:
RFC 768 User Datagram Protocol (three pages long in entirety)
> Checksum is the 16-bit one's complement of the one's complement sum
> of [],  padded  with zero octets at the end (if  necessary) to
> make a multiple of two octets.

While this particular method has some issues, does the solution
really need more complexity than that? This should not require
more than about 6 lines of code.

I have faith in your abilities! You are qualified to choose a simple
data structure hash function for your spec and have it not suck. No one
will accuse you of "inventing your own cryptography" or engineering
after having read Schneier's book. If they do, I will be by your side!

Just do it!

:-)

- Marsh

On 3/2/2010 3:53 PM, Stefan Santesson wrote:
> It seems that we have some decisions to make here. Hopefully we can
> sort them out in Anaheim and then move on to closure.
> 
> /Stefan
> 
>> It looks to me that the client-side hash computation option is
>> simpler if we don't try to build in agility and negotiation.  If we
>> feel we need these then having the server assign an identity for
>> these values seems simpler.
>> 
>> Joe
>> 
>>> -----Original Message----- From: Brian Smith
>>> [mailto:[email-masked]] Sent: Monday, March 01, 2010 6:29
>>> AM To: Stefan Santesson Cc: Joseph Salowey (jsalowey); Simon
>>> Josefsson; [email-masked] Subject: Re: [TLS]
>>> draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
>>> 
>>> Stefan Santesson wrote:
>>>> The original approach have two functions 1) Client informs the
>>>> server what information it has cached 2) Server accepts caching
>>>> and replaces the data with the hash provided
>>> by
>>>> the client
>>>> 
>>>> In the alternative approach this is expanded to: 1) The client
>>>> tells server that it wants to cache data 2) The server provides
>>>> hashes/identifiers of info the client may cache 3) The client
>>>> signals that it has cached info with identifiers provided
>>> by
>>>> the server 4) The server replaces cached data
>>>> 
>>>> I see no reason to make the protocol any more complex than it
>>>> need to
>>> be.
>>>> 
>>> In the alternative approach, there is no need to pass multiple
>>> hashes of the same item back/forth, so the syntax becomes
>>> simpler. Also, the client and server do not have to agree on a
>>> hash algorithm at all, which is a big simplification. The client
>>> doesn't have to calculate anything, which is a further
>>> simplification.
>>> 
>>> Many clients won't want to cache this information unless the
>>> server says that it supports the extension. That is why Adam
>>> Langley and others have asked for a ServerHello extension that
>>> indicates the items for which the server supports caching. It is
>>> very easy for the server to just stuff the identifiers inside
>>> that extension.
>>> 
>>> Regards, Brian
> 
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 02 Mar 2010 23:58:49 +0100

> negotiate the truncated cryptographic hash function that is used to pick

I support your earlier suggestion to use the FNV algorithm for the
checksum.

/Simon

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 03 Mar 2010 15:48:58 +0100

Looking at FNV it is simple enough that a complete specification of a 64 bit
FNV calculation could be included in the document.

It does have the advantage of removing the whole agility and hash
negotiation issue which is a good thing.

However, is it possible to unite all wills here?

Who would object if we select FNV hash instead of a cryptographic hash
function?

/Stefan

---

From: Adam Langley <[email-masked]>
Date: Wed, 3 Mar 2010 10:00:47 -0500

> Who would object if we select FNV hash instead of a cryptographic hash

I can't think of any problems.

AGL

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 03 Mar 2010 08:04:23 -0800

I support the use of FNV.  I've been using the 32-bit version in my
Hash containers for many years.

Mike