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

[Marsh Ray <[e-mail]>]

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
> 
> On 10-03-02 6:30 PM, "Joseph Salowey (jsalowey)" <[e-mail]>
> 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
>> 
>>> -----Original Message----- From: Brian Smith
>>> [mailto:[e-mail]] Sent: Monday, March 01, 2010 6:29
>>> AM To: Stefan Santesson Cc: Joseph Salowey (jsalowey); Simon
>>> Josefsson; [e-mail] Subject: Re: [TLS]
>>> draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
>>> 
>>> Stefan Santesson wrote:
>>>> 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.
>>>> 
>>> 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 
> [e-mail] https://www.ietf.org/mailman/listinfo/tls