Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
Marsh Ray <marsh@extendedsubset.com> Tue, 02 March 2010 22:34 UTC
Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id ED33028C288 for <tls@core3.amsl.com>;
Tue, 2 Mar 2010 14:34:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwRfneOW+BFj for
<tls@core3.amsl.com>; Tue, 2 Mar 2010 14:34:58 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71])
by core3.amsl.com (Postfix) with ESMTP id 835AD28C1D3 for <tls@ietf.org>;
Tue, 2 Mar 2010 14:34:57 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by
mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from
<marsh@extendedsubset.com>) id 1Nmag4-0000rY-FM;
Tue, 02 Mar 2010 22:34:56 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com
(Postfix) with ESMTP id EE3DF64E7; Tue, 2 Mar 2010 22:34:53 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see
http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse
reporting information)
X-MHO-User: U2FsdGVkX193FO4bE3ZI2L0VosqCbBmcELOfWIb1WLo=
Message-ID: <4B8D9290.4040806@extendedsubset.com>
Date: Tue, 02 Mar 2010 16:34:56 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Stefan Santesson <stefan@aaa-sec.com>
References: <C7B34787.8C15%stefan@aaa-sec.com>
In-Reply-To: <C7B34787.8C15%stefan@aaa-sec.com>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson <simon@josefsson.org>, tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working
group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>,
<mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>,
<mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2010 22:34:59 -0000
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)" <jsalowey@cisco.com> > 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:brian@briansmith.org] Sent: Monday, March 01, 2010 6:29 >>> AM To: Stefan Santesson Cc: Joseph Salowey (jsalowey); Simon >>> Josefsson; tls@ietf.org 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 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Nikos Mavrogiannopoulos
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Michael D'Errico
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Nikos Mavrogiannopoulos
- Re: [TLS] Android's cut-through mode & "RequestTi… Brian Smith
- [TLS] Stream multiplexing extension RE: SPDY / Ne… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- [TLS] TLS Performance (was Re: draft-ietf-tls-cac… Michael D'Errico
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Kemp, David P.
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- [TLS] Cached-info substitution Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Kemp, David P.
- Re: [TLS] Cached-info substitution Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] Cached-info substitution Adam Langley
- Re: [TLS] Cached-info substitution Brian Smith
- Re: [TLS] Cached-info substitution Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] Cached-info substitution Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Kemp, David P.
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- [TLS] RFC 5077 (was Re: draft-ietf-tls-cached-inf… Michael D'Errico
- Re: [TLS] Cached-info substitution Adam Langley
- Re: [TLS] Cached-info substitution Wan-Teh Chang
- Re: [TLS] Cached-info substitution Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Kemp, David P.
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Marsh Ray
- Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-cach… Kemp, David P.
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Marsh Ray
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Yoav Nir
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Joseph Salowey (jsalowey)
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Brian Smith
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Martin Rex
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Donald Eastlake
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Joseph Salowey (jsalowey)
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Marsh Ray
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Simon Josefsson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Stefan Santesson
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Adam Langley
- Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fa… Michael D'Errico