From stefan@aaa-sec.com Thu Jun 4 10:41:14 2009 Return-Path: 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 E62813A6E21 for ; Thu, 4 Jun 2009 10:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 OXsnsBiB5B7e for ; Thu, 4 Jun 2009 10:41:12 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id F189B3A6DB3 for ; Thu, 4 Jun 2009 10:41:08 -0700 (PDT) Received: (qmail 3310 invoked from network); 4 Jun 2009 17:41:15 -0000 Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 4 Jun 2009 17:41:15 -0000 Received: (qmail 67970 invoked from network); 4 Jun 2009 17:41:08 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 Jun 2009 17:41:08 -0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 04 Jun 2009 19:41:07 +0200 From: Stefan Santesson To: TLS wg Message-ID: Thread-Topic: First TLS cached information draft posted Thread-Index: AcnlO6PBlXmAY4WdFEeoge4+B0iYEg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3326989268_8683981" Subject: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 17:41:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3326989268_8683981 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I have finally incorporated the agreed changes to what previously was calle= d the cached certs extension, now changed to the cached information extension= , and submitted the first (00) TLS draft. The draft is available from the following staging URL until it=B9s made available as a TLS draft. http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-info-00.txt I hope I didn=B9t miss any agreed changes. /Stefan --B_3326989268_8683981 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable First TLS cached information draft posted I have finally incorporated the agreed changes to what previously was call= ed the cached certs extension, now changed to the cached information extensi= on, and submitted the first (00) TLS draft.

The draft is available from the following staging URL until it’s made= available as a TLS draft.
http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-info-= 00.txt

I hope I didn’t miss any agreed changes.

/Stefan --B_3326989268_8683981-- From simon@josefsson.org Fri Jun 5 04:38:30 2009 Return-Path: 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 BC7BA3A6CBA for ; Fri, 5 Jun 2009 04:38:30 -0700 (PDT) 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=[AWL=0.000, 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 nwyxYOgim+BU for ; Fri, 5 Jun 2009 04:38:29 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 81C2F3A6BA8 for ; Fri, 5 Jun 2009 04:38:28 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n55BcO9G024881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Jun 2009 13:38:27 +0200 From: Simon Josefsson To: Stefan Santesson References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090605:tls@ietf.org::DcPCVVl5lPHNI9wR:EHFX X-Hashcash: 1:22:090605:stefan@aaa-sec.com::tymxI0ax7Y2GLcsG:kP8B Date: Fri, 05 Jun 2009 13:38:24 +0200 In-Reply-To: (Stefan Santesson's message of "Thu, 04 Jun 2009 19:41:07 +0200") Message-ID: <87fxeerjv3.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: TLS wg Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 11:38:30 -0000 Stefan Santesson writes: > I have finally incorporated the agreed changes to what previously was called > the cached certs extension, now changed to the cached information extension, > and submitted the first (00) TLS draft. > > The draft is available from the following staging URL until itıs made > available as a TLS draft. > http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-info-00.txt I support this. I've seen 40kb handshakes due to the server return a list of acceptable CAs, and that has generated some interop problems with GnuTLS [1]. The document appears to be in good shape. I believe I could implement the document if two (minor) concerns were resolved. First, this paragraph: Servers that receive an extended client hello containing a "cached_information" extension, MAY indicate that they support one or more of the cached information objects by including an extension of type "cached_information" in the (extended) server hello, which SHALL contain at least one CachedObject received from the client. The intention here appears under-specified. What does it mean if the client sent two CachedObject's and the server just returned one of them? One plausible interpretation would be that the server did not support the hash/type-combination that were not returned. Enforcing that interpretation is needed to resolve my second concern. I suggest to add a sentence: The CachedObject's returned by the server MUST include the types the server supports and has accepted to replace with cached data. Secondly, this paragraph: After negotiation of the use of cached certificates has been successfully completed (by exchanging hello messages including "cached_certs" extensions), the server MAY replace the cached information objects in its handshake messages with a corresponding hash_value from CachedInformationHash that was included in the cached_information extension of the server hello message. Why a MAY here? How would a client distinguish whether the server did replace the data or not? Why not use the extended server hello to return the supported types (as suggested above)? This appears to add complexity for no particular reason, at least as far as I can understand. I suggest to replace MAY with MUST here. Thanks, /Simon [1] GnuTLS refuses large handshakes due to DoS concerns, and we had to increase the limit. From stefan@aaa-sec.com Fri Jun 5 05:29:13 2009 Return-Path: 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 882863A687C for ; Fri, 5 Jun 2009 05:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 r7wH4HQCKGpP for ; Fri, 5 Jun 2009 05:29:12 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 277AA3A6872 for ; Fri, 5 Jun 2009 05:29:11 -0700 (PDT) Received: (qmail 98410 invoked from network); 5 Jun 2009 12:29:16 -0000 Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 5 Jun 2009 12:29:16 -0000 Received: (qmail 56993 invoked from network); 5 Jun 2009 12:29:11 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Jun 2009 12:29:11 -0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 05 Jun 2009 14:29:10 +0200 From: Stefan Santesson To: Simon Josefsson Message-ID: Thread-Topic: First TLS cached information draft posted Thread-Index: Acnl2Tn45WkNeU1LbEyc56lzw2NeDA== In-Reply-To: <87fxeerjv3.fsf@mocca.josefsson.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: TLS wg Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 12:29:13 -0000 Thank's Simon, Good comments and I agree to both of them. 1) Yes the intension is that if the server returns only 1 out of 2 objects, only the object returned will be replaced 2) If the server has indicated support of a cached object in the server hello, the requirement to replace that object with a hash should be a MUST. It turns out that it was not to late to cancel the submission, so I have already incorporated this in the 00 draft and resubmitted. If you follow the same link and hit "refresh" you will see the changes. /Stefan On 09-06-05 1:38 PM, "Simon Josefsson" wrote: > Stefan Santesson writes: >=20 >> I have finally incorporated the agreed changes to what previously was ca= lled >> the cached certs extension, now changed to the cached information extens= ion, >> and submitted the first (00) TLS draft. >>=20 >> The draft is available from the following staging URL until it=B9s made >> available as a TLS draft. >> http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-info-00.tx= t >=20 > I support this. I've seen 40kb handshakes due to the server return a > list of acceptable CAs, and that has generated some interop problems > with GnuTLS [1]. >=20 > The document appears to be in good shape. I believe I could implement > the document if two (minor) concerns were resolved. >=20 > First, this paragraph: >=20 > Servers that receive an extended client hello containing a > "cached_information" extension, MAY indicate that they support one or > more of the cached information objects by including an extension of > type "cached_information" in the (extended) server hello, which SHALL > contain at least one CachedObject received from the client. >=20 > The intention here appears under-specified. What does it mean if the > client sent two CachedObject's and the server just returned one of them? > One plausible interpretation would be that the server did not support > the hash/type-combination that were not returned. Enforcing that > interpretation is needed to resolve my second concern. >=20 > I suggest to add a sentence: >=20 > The CachedObject's returned by the server MUST include the types the > server supports and has accepted to replace with cached data. >=20 > Secondly, this paragraph: >=20 > After negotiation of the use of cached certificates has been > successfully completed (by exchanging hello messages including > "cached_certs" extensions), the server MAY replace the cached > information objects in its handshake messages with a corresponding > hash_value from CachedInformationHash that was included in the > cached_information extension of the server hello message. >=20 > Why a MAY here? How would a client distinguish whether the server did > replace the data or not? Why not use the extended server hello to > return the supported types (as suggested above)? This appears to add > complexity for no particular reason, at least as far as I can > understand. >=20 > I suggest to replace MAY with MUST here. >=20 > Thanks, > /Simon >=20 > [1] GnuTLS refuses large handshakes due to DoS concerns, and we had to > increase the limit. From simon@josefsson.org Fri Jun 5 05:36:07 2009 Return-Path: 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 9DCB13A6D02 for ; Fri, 5 Jun 2009 05:36:07 -0700 (PDT) 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 k7HJHGHtfvv6 for ; Fri, 5 Jun 2009 05:36:07 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 781003A6A4F for ; Fri, 5 Jun 2009 05:36:06 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n55Ca5sh026272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Jun 2009 14:36:06 +0200 From: Simon Josefsson To: Stefan Santesson References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090605:tls@ietf.org::mT455dAKlfMH1YhY:CEdS X-Hashcash: 1:22:090605:stefan@aaa-sec.com::PoTeCJ5W5mFHnBn9:YgV+ Date: Fri, 05 Jun 2009 14:36:05 +0200 In-Reply-To: (Stefan Santesson's message of "Fri, 05 Jun 2009 14:29:10 +0200") Message-ID: <87vdnavowa.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS wg Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 12:36:07 -0000 Stefan Santesson writes: > Thank's Simon, > > Good comments and I agree to both of them. > > 1) Yes the intension is that if the server returns only 1 out of 2 objects, > only the object returned will be replaced > > 2) If the server has indicated support of a cached object in the server > hello, the requirement to replace that object with a hash should be a MUST. > > It turns out that it was not to late to cancel the submission, so I have > already incorporated this in the 00 draft and resubmitted. > > If you follow the same link and hit "refresh" you will see the changes. Looks fine, thank you. A minor discussion would be whether adding support for SHA-256/384/512 is worthwhile, but I don't feel strongly either way. If someone is looking into implementing this specification, I'm interested in performing interop testing. /Simon From stefan@aaa-sec.com Fri Jun 5 10:04:23 2009 Return-Path: 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 6F0C33A68F2 for ; Fri, 5 Jun 2009 10:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 sjJQi4f-2dW3 for ; Fri, 5 Jun 2009 10:04:22 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 4F86A3A68C9 for ; Fri, 5 Jun 2009 10:04:22 -0700 (PDT) Received: (qmail 5544 invoked from network); 5 Jun 2009 17:04:29 -0000 Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 5 Jun 2009 17:04:29 -0000 Received: (qmail 33514 invoked from network); 5 Jun 2009 17:04:22 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Jun 2009 17:04:22 -0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 05 Jun 2009 19:04:22 +0200 From: Stefan Santesson To: Simon Josefsson Message-ID: Thread-Topic: First TLS cached information draft posted Thread-Index: Acnl/6vjK7l0ISAUJESeaAbYqsB53Q== In-Reply-To: <87vdnavowa.fsf@mocca.josefsson.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: TLS wg Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 17:04:23 -0000 Simon, The specification allows you to specify and use any hash algorithm that is supported by the TLS hash algorithm registry. SHA-1 is the only MUST support algorithm, and I think that is correct. /Stefan On 09-06-05 2:36 PM, "Simon Josefsson" wrote: > A minor discussion would be whether adding support for SHA-256/384/512 > is worthwhile, but I don't feel strongly either way. From Martin.Rex@sap.com Fri Jun 5 13:55:54 2009 Return-Path: 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 9CEBF3A67F6 for ; Fri, 5 Jun 2009 13:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 g9DxdWxQdk3q for ; Fri, 5 Jun 2009 13:55:53 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 921403A67B5 for ; Fri, 5 Jun 2009 13:55:53 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n55KtrjI029504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 22:55:53 +0200 (MEST) From: Martin Rex Message-Id: <200906052055.n55KtrQ2024766@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Fri, 5 Jun 2009 22:55:53 +0200 (MEST) In-Reply-To: <87fxeerjv3.fsf@mocca.josefsson.org> from "Simon Josefsson" at Jun 5, 9 01:38:24 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 20:55:54 -0000 Simon Josefsson wrote: > > First, this paragraph: > > Servers that receive an extended client hello containing a > "cached_information" extension, MAY indicate that they support one or > more of the cached information objects by including an extension of > type "cached_information" in the (extended) server hello, which SHALL > contain at least one CachedObject received from the client. > > The intention here appears under-specified. What does it mean if the > client sent two CachedObject's and the server just returned one of them? > One plausible interpretation would be that the server did not support > the hash/type-combination that were not returned. Enforcing that > interpretation is needed to resolve my second concern. > > I suggest to add a sentence: > > The CachedObject's returned by the server MUST include the types the > server supports and has accepted to replace with cached data. I don't know whether I correctly understand the suggestion that you're making. But I'm very unhappy with one possible interpretation that I see in your poposal. Having the TLS server indicate for which objects its TLS implementation supports the caching _in_principle_ is fine with me. Requiring the server to already know the hash values of parts the contents of future SSL handshake messages, specifically the to-be-cached data at the time when composing the ServerHello handshake message is something I would definitely not like. The impact on implementations of TLS should be as small as possible. To me, a requirement for a TLS server to precompute hashes over parts of future handshake messages during ServerHello looks like a significant additional burden, and personally, I do not yet see any benefit this might provide. -Martin From stefan@aaa-sec.com Fri Jun 5 18:17:12 2009 Return-Path: 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 06D493A6901 for ; Fri, 5 Jun 2009 18:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 lSxIUCtKG3Qo for ; Fri, 5 Jun 2009 18:17:11 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id BBF473A687A for ; Fri, 5 Jun 2009 18:17:09 -0700 (PDT) Received: (qmail 69206 invoked from network); 6 Jun 2009 01:17:20 -0000 Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 6 Jun 2009 01:17:20 -0000 Received: (qmail 49394 invoked from network); 6 Jun 2009 01:17:10 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 6 Jun 2009 01:17:10 -0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sat, 06 Jun 2009 03:17:08 +0200 From: Stefan Santesson To: , Simon Josefsson Message-ID: Thread-Topic: [TLS] First TLS cached information draft posted Thread-Index: AcnmRIKZ8VcrZfh87UavqXY8qgfrGg== In-Reply-To: <200906052055.n55KtrQ2024766@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 01:17:12 -0000 Martin, I liked Simon's suggestion as he expressed my original thought that the Server would know beforehand the hashes for acceptable information objects. However, what you suggest actually makes sense to me. I also found another minor error as the draft refer to hash_value (single hash) when I should refer to the "hashes" (multiple hash) element. We have to think through the concept of sending over multiple hashes and what the appropriate response from the server is. 1) The server accepts replacement in principle, but does not know at the time of sending the server hello if any of the hashes match. 2) The server accepts one or more hashes from the client hello (for one object type) and includes the hashes it accepts in the server hello 3) The server accepts one or more hashes from the client hello (for one object type) but includes only 1 (the preferred one) hash for that object type in the server hello. Once we can agree on this, I will update and submit a new version of the draft. /Stefan On 09-06-05 10:55 PM, "Martin Rex" wrote: > Simon Josefsson wrote: >> >> First, this paragraph: >> >> Servers that receive an extended client hello containing a >> "cached_information" extension, MAY indicate that they support one or >> more of the cached information objects by including an extension of >> type "cached_information" in the (extended) server hello, which SHALL >> contain at least one CachedObject received from the client. >> >> The intention here appears under-specified. What does it mean if the >> client sent two CachedObject's and the server just returned one of them? >> One plausible interpretation would be that the server did not support >> the hash/type-combination that were not returned. Enforcing that >> interpretation is needed to resolve my second concern. >> >> I suggest to add a sentence: >> >> The CachedObject's returned by the server MUST include the types the >> server supports and has accepted to replace with cached data. > > I don't know whether I correctly understand the suggestion > that you're making. But I'm very unhappy with one possible > interpretation that I see in your poposal. > > Having the TLS server indicate for which objects its TLS implementation > supports the caching _in_principle_ is fine with me. > > Requiring the server to already know the hash values of > parts the contents of future SSL handshake messages, specifically > the to-be-cached data at the time when composing the ServerHello > handshake message is something I would definitely not like. > > The impact on implementations of TLS should be as small as possible. > To me, a requirement for a TLS server to precompute hashes over > parts of future handshake messages during ServerHello looks like > a significant additional burden, and personally, I do not yet see > any benefit this might provide. > > > -Martin From stefan@aaa-sec.com Sun Jun 7 01:46:54 2009 Return-Path: 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 CFB233A6879 for ; Sun, 7 Jun 2009 01:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 i5Ii9IPEcT1k for ; Sun, 7 Jun 2009 01:46:54 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 68E753A67A4 for ; Sun, 7 Jun 2009 01:46:51 -0700 (PDT) Received: (qmail 82389 invoked from network); 7 Jun 2009 08:46:56 -0000 Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 7 Jun 2009 08:46:56 -0000 Received: (qmail 15881 invoked from network); 7 Jun 2009 08:46:52 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 Jun 2009 08:46:52 -0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sun, 07 Jun 2009 10:46:52 +0200 From: Stefan Santesson To: Stefan Santesson , , Simon Josefsson Message-ID: Thread-Topic: [TLS] First TLS cached information draft posted Thread-Index: AcnmRIKZ8VcrZfh87UavqXY8qgfrGgBB/4iC In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 08:46:54 -0000 I think I have to try to clarify this The client send a cached_information extension which contains a list of CachedObject structures. Each ChachedObject element contains: - type identifier (CachedInformationType type) - a list of hash values (CachedInformationHash hashes) Each CachedInformationHash contains: - Algorithm identifier (HashAlgorithm hash) - Hash value (opaque hash_value) There are a number of issues that need to be specified or clarified in the draft: 1) Is it allowed to send over multiple CachedObject elements containing the same type identifier? Proposed answer = No (you can already include multiple hashes for each type) 2) What should the server return in its server hello message for each acceptable CachedObject? Alternative 1 = The CachedObject element, exactly as it was received by the client (with all hashes) Alternative 2 = The CachedObject element, but only containing the CachedInformationHash elements that is recognize and support. Proposed answer = Alternative 1 (This allows the server to say YES in principle without analyzing the hash values at the time of Hello exchange) 3) Is the server REQUIRED to honor its support of a CachedObject by replacing the identified handshake data with a received hash? Proposed answer = NO (for reasons raised by Martin) 4) What does the server send as replacement for the replaced handshake data? Proposed answer = One opaque hash_value (without hash type identifier) that was received by the client, which MUST contain a valid hash over the replaced data. Do you agree? /Stefan On 09-06-06 3:17 AM, "Stefan Santesson" wrote: > Martin, > > I liked Simon's suggestion as he expressed my original thought that the > Server would know beforehand the hashes for acceptable information objects. > > However, what you suggest actually makes sense to me. > > I also found another minor error as the draft refer to hash_value (single > hash) when I should refer to the "hashes" (multiple hash) element. > > We have to think through the concept of sending over multiple hashes and > what the appropriate response from the server is. > > 1) The server accepts replacement in principle, but does not know at the > time of sending the server hello if any of the hashes match. > > 2) The server accepts one or more hashes from the client hello (for one > object type) and includes the hashes it accepts in the server hello > > 3) The server accepts one or more hashes from the client hello (for one > object type) but includes only 1 (the preferred one) hash for that object > type in the server hello. > > Once we can agree on this, I will update and submit a new version of the > draft. > > /Stefan > > > > > On 09-06-05 10:55 PM, "Martin Rex" wrote: > >> Simon Josefsson wrote: >>> >>> First, this paragraph: >>> >>> Servers that receive an extended client hello containing a >>> "cached_information" extension, MAY indicate that they support one or >>> more of the cached information objects by including an extension of >>> type "cached_information" in the (extended) server hello, which SHALL >>> contain at least one CachedObject received from the client. >>> >>> The intention here appears under-specified. What does it mean if the >>> client sent two CachedObject's and the server just returned one of them? >>> One plausible interpretation would be that the server did not support >>> the hash/type-combination that were not returned. Enforcing that >>> interpretation is needed to resolve my second concern. >>> >>> I suggest to add a sentence: >>> >>> The CachedObject's returned by the server MUST include the types the >>> server supports and has accepted to replace with cached data. >> >> I don't know whether I correctly understand the suggestion >> that you're making. But I'm very unhappy with one possible >> interpretation that I see in your poposal. >> >> Having the TLS server indicate for which objects its TLS implementation >> supports the caching _in_principle_ is fine with me. >> >> Requiring the server to already know the hash values of >> parts the contents of future SSL handshake messages, specifically >> the to-be-cached data at the time when composing the ServerHello >> handshake message is something I would definitely not like. >> >> The impact on implementations of TLS should be as small as possible. >> To me, a requirement for a TLS server to precompute hashes over >> parts of future handshake messages during ServerHello looks like >> a significant additional burden, and personally, I do not yet see >> any benefit this might provide. >> >> >> -Martin > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From rdugal@certicom.com Mon Jun 8 06:52:52 2009 Return-Path: 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 807453A6ADC for ; Mon, 8 Jun 2009 06:52:52 -0700 (PDT) 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 Q7ljD8hTI+ZY for ; Mon, 8 Jun 2009 06:52:51 -0700 (PDT) Received: from cx296.800onemail.com (CX296.800onemail.com [209.171.54.154]) by core3.amsl.com (Postfix) with ESMTP id 4B9E03A6977 for ; Mon, 8 Jun 2009 06:52:47 -0700 (PDT) Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx296.800onemail.com (8.13.8/8.13.8) with ESMTP id n58DqRdH005150; Mon, 8 Jun 2009 09:52:27 -0400 Received: from EX41.exchserver.com ([169.254.1.219]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Mon, 8 Jun 2009 09:52:27 -0400 From: Rob Dugal To: Joseph Birr-Pixton , "tls@ietf.org" Date: Mon, 8 Jun 2009 09:52:25 -0400 Thread-Topic: [TLS] TLS1.2 PRF test vectors Thread-Index: AcnDYS61Sz9wydWXTS6bxRVJo34uIgk3wI2Q Message-ID: <1DB83EE5F276854387927FA5A7E06FC1F2FAAE2F3E@EX41.exchserver.com> References: <1240414745.6318.234.camel@bewdley> In-Reply-To: <1240414745.6318.234.camel@bewdley> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CRXEFW-Info: Please contact Ceryx for more information X-CRXEFW-Virus: Clean X-CRXEFW-From: rdugal@certicom.com Subject: Re: [TLS] TLS1.2 PRF test vectors 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 13:52:52 -0000 These results are consistent with our implementation. > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Jos= eph Birr-Pixton > Sent: Wednesday, April 22, 2009 11:39 AM > To: tls@ietf.org > Subject: [TLS] TLS1.2 PRF test vectors >=20 > Greetings, >=20 > I have failed to find any published test vectors for this algorithm, or a= ny implementation to test > against. Therefore I've generated some in the hope that somebody can agr= ee with or dispute my > results. >=20 > I've covered all hash functions from the SHA-2 family. >=20 > Thanks, >=20 > -- > Joseph Birr-Pixton > Senior Software Engineer > THALES Information Systems Security > nCipher Product Line > ------------------------------------------------------- > E: jbp@ncipher.com > W: http://www.ncipher.com/ >=20 >=20 > nCipher Corporation Limited is incorporated in England and Wales with com= pany registration number > 3169278. Its registered office is located at Jupiter House, Station Road,= Cambridge, Cambs, CB1 2JD. >=20 > The information contained in this e-mail is confidential. It may also be = privileged. It is only > intended for the stated addressee(s) and access to it by any other person= is unauthorised. If you are > not an addressee or the intended addressee, you must not disclose, copy, = circulate or in any other way > use or rely on the information contained in this e-mail. Such unauthorise= d use may be unlawful. If you > have received this e-mail in error please delete it (and all copies) from= your system, please also > inform us immediately on +44 (0)1223 723600 or email sales@ncipher.com. C= ommercial matters detailed or > referred to in this e-mail are subject to a written contract signed for a= nd on behalf of nCipher > Corporation Limited. From sshen@huawei.com Mon Jun 8 17:58:15 2009 Return-Path: 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 1F47728C17D for ; Mon, 8 Jun 2009 17:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.107 X-Spam-Level: *** X-Spam-Status: No, score=3.107 tagged_above=-999 required=5 tests=[AWL=1.151, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] 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 cVd3TEXHViZb for ; Mon, 8 Jun 2009 17:58:14 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id E04F33A6C15 for ; Mon, 8 Jun 2009 17:58:13 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKY002OG5CWXD@szxga01-in.huawei.com> for TLS@ietf.org; Tue, 09 Jun 2009 08:58:09 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKY00JZO5CWJX@szxga01-in.huawei.com> for TLS@ietf.org; Tue, 09 Jun 2009 08:58:08 +0800 (CST) Received: from s00102542 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKY00AB85CWLP@szxml04-in.huawei.com> for TLS@ietf.org; Tue, 09 Jun 2009 08:58:08 +0800 (CST) Date: Tue, 09 Jun 2009 08:58:13 +0800 From: Sean Shen To: TLS@ietf.org Message-id: <001201c9e89d$5db40c40$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_9QrrR5XriHIXUsuNxNghFA)" Thread-index: AcnlO6PBlXmAY4WdFEeoge4+B0iYEgCsiy/QACvXePA= Subject: [TLS] FWD: First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 00:58:15 -0000 This is a multi-part message in MIME format. --Boundary_(ID_9QrrR5XriHIXUsuNxNghFA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable It looks this message was not sent out successfully, have to try it = again. =20 _____ =20 =B7=A2=BC=FE=C8=CB: Sean Shen [mailto:sshen@huawei.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA6=D4=C28=C8=D5 12:08 =CA=D5=BC=FE=C8=CB: 'Stefan Santesson'; 'TLS wg' =D6=F7=CC=E2: =B4=F0=B8=B4: [TLS] First TLS cached information draft = posted Hi, Stefan, I support the idea and like the benefit of not transporting Certs. The drafts looks good and clear to me, except that I get some questions regarding the following part in section 4: =20 Servers that receive an extended client hello containing a "cached_information" extension, MAY indicate that they support one or more of the cached information objects by including an extension of type "cached_information" in the (extended) server hello, which SHALL contain at least one CachedObject received from the client. The CachedObject's returned by the server MUST include the types the server supports and has accepted to replace with a hash of the cached data.=20 =20 It gives me impression that server's reply can include items that is = beyond cached items which=20 clients provide. Is it possible (or leagal) for clients to use those = items which he did not=20 mentioned but were indicated usable by server?=20 For example clients provides items {A, B}, server replied {B, C}.=20 B has been confirmed by both sides, C is confirmed only by Server. If B = and C are both acceptable,=20 but the two negotiation base are not quite same, will there be a problem = ? Not quite sure it would=20 cause trouble or not though, but wondering whether it will. For example, since hello message are not crypto protected yet, is it possible for a man-in-middle to=20 let clients accept expired certs or fake CAs? =20 Sean =20 =20 _____ =20 =B7=A2=BC=FE=C8=CB: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] = =B4=FA=B1=ED Stefan Santesson =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA6=D4=C25=C8=D5 1:41 =CA=D5=BC=FE=C8=CB: TLS wg =D6=F7=CC=E2: [TLS] First TLS cached information draft posted I have finally incorporated the agreed changes to what previously was = called the cached certs extension, now changed to the cached information = extension, and submitted the first (00) TLS draft. The draft is available from the following staging URL until it=A1=AFs = made available as a TLS draft. http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-info-00.txt= I hope I didn=A1=AFt miss any agreed changes. /Stefan=20 --Boundary_(ID_9QrrR5XriHIXUsuNxNghFA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable First TLS cached information draft posted
It = looks this=20 message was not sent out successfully, have to try it = again.
 

=B7=A2=BC=FE=C8=CB: Sean Shen = [mailto:sshen@huawei.com]
=B7=A2=CB=CD=CA=B1=BC=E4:=20 2009=C4=EA6=D4=C28=C8=D5 12:08
=CA=D5=BC=FE=C8=CB: 'Stefan = Santesson'; 'TLS wg'
=D6=F7=CC=E2: =B4=F0=B8=B4:=20 [TLS] First TLS cached information draft posted

Hi,=20 Stefan,
I = support the=20 idea and like the benefit of not transporting = Certs.
The drafts=20 looks good and clear to me, except that I get some questions = regarding the following part in section 4:
 
   Servers that receive = an extended=20 client hello containing a
   "cached_information" = extension, MAY=20 indicate that they support one or
   more of the cached=20 information objects by including an extension of
   type=20 "cached_information" in the (extended) server hello, which=20 SHALL
   contain at least one CachedObject received from = the=20 client. The
   CachedObject's returned by the server MUST = include=20 the types the
   server supports and has accepted to = replace with=20 a hash of the cached
   data.
 
It gives me impression that = server's reply can=20 include items that is beyond cached items which
clients provide. Is it possible = (or leagal)=20 for clients to use those items which he did not
mentioned but were indicated = usable by server?=20
For example clients provides items {A, B}, server replied {B, C}. =
B=20 has been confirmed by both sides, C is confirmed only by Server. If B = and C=20 are both acceptable,
but the two negotiation base are = not quite=20 same, will there be a problem ? Not quite sure it would
cause trouble or not though, but = wondering=20 whether it will.
For example, since hello message are not crypto = protected=20 yet, is it possible for a man-in-middle to
let clients accept expired certs = or fake=20 CAs?
 
Sean
 
 

=B7=A2=BC=FE=C8=CB: tls-bounces@ietf.org = [mailto:tls-bounces@ietf.org]=20 =B4=FA=B1=ED Stefan = Santesson
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA6=D4=C25=C8=D5 = 1:41
=CA=D5=BC=FE=C8=CB: TLS=20 wg
=D6=F7=CC=E2: [TLS] First TLS cached information draft=20 posted

I have finally incorporated the agreed = changes to=20 what previously was called the cached certs extension, now changed = to the=20 cached information extension, and submitted the first (00) TLS=20 draft.

The draft is available from the following staging URL = until=20 it=A1=AFs made available as a TLS draft.
http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-i= nfo-00.txt

I=20 hope I didn=A1=AFt miss any agreed = changes.

/Stefan=20
--Boundary_(ID_9QrrR5XriHIXUsuNxNghFA)-- From simon@josefsson.org Mon Jun 8 23:27:18 2009 Return-Path: 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 CD1143A6C4E for ; Mon, 8 Jun 2009 23:27:18 -0700 (PDT) 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 9Lsp9h+DyY+Q for ; Mon, 8 Jun 2009 23:27:17 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 5DBEC3A6C36 for ; Mon, 8 Jun 2009 23:27:16 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n596Qu46026497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jun 2009 08:26:58 +0200 From: Simon Josefsson To: Sean Shen References: <001201c9e89d$5db40c40$800c6f0a@china.huawei.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090609:tls@ietf.org::6OfHIr4Y3imkABgH:85v X-Hashcash: 1:22:090609:sshen@huawei.com::kDBpuKMwVb9ENxNS:5SWw Date: Tue, 09 Jun 2009 08:26:55 +0200 In-Reply-To: <001201c9e89d$5db40c40$800c6f0a@china.huawei.com> (Sean Shen's message of "Tue, 09 Jun 2009 08:58:13 +0800") Message-ID: <87vdn5kjm8.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] FWD: First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 06:27:18 -0000 Sean Shen writes: > Hi, Stefan, > I support the idea and like the benefit of not transporting Certs. > The drafts looks good and clear to me, except that I get some questions > regarding the following part in section 4: > > Servers that receive an extended client hello containing a > "cached_information" extension, MAY indicate that they support one or > more of the cached information objects by including an extension of > type "cached_information" in the (extended) server hello, which SHALL > contain at least one CachedObject received from the client. The > CachedObject's returned by the server MUST include the types the > server supports and has accepted to replace with a hash of the cached > data. > > It gives me impression that server's reply can include items that is beyond > cached items which > clients provide. Is it possible (or leagal) for clients to use those items > which he did not > mentioned but were indicated usable by server? > For example clients provides items {A, B}, server replied {B, C}. > B has been confirmed by both sides, C is confirmed only by Server. If B and > C are both acceptable, > but the two negotiation base are not quite same, will there be a problem ? > Not quite sure it would > cause trouble or not though, but wondering whether it will. Good point. I don't see how that could work -- how would the server know whether the client supported C? The client needs to understand C in order to parse the handshake properly. /Simon From simon@josefsson.org Mon Jun 8 23:37:16 2009 Return-Path: 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 B1CC93A6CD9 for ; Mon, 8 Jun 2009 23:37:16 -0700 (PDT) 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=[AWL=0.000, 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 Eee1qBQPiT8O for ; Mon, 8 Jun 2009 23:37:15 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 5506B3A6CD5 for ; Mon, 8 Jun 2009 23:37:15 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n596bEjI026611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jun 2009 08:37:16 +0200 From: Simon Josefsson To: Stefan Santesson References: <87vdnavowa.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090609:stefan@aaa-sec.com::IBbEXlOYCpYX3GYE:69IG X-Hashcash: 1:22:090609:tls@ietf.org::mIc5h7WN/A2E4nup:ByDE Date: Tue, 09 Jun 2009 08:37:14 +0200 In-Reply-To: (Stefan Santesson's message of "Fri, 05 Jun 2009 19:04:22 +0200") Message-ID: <87r5xtkj51.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS wg Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 06:37:16 -0000 Stefan Santesson writes: > Simon, > > The specification allows you to specify and use any hash algorithm that is > supported by the TLS hash algorithm registry. > > SHA-1 is the only MUST support algorithm, and I think that is correct. That's fine. In practice, I guess client implementations are likely to send: CachedInformation = { { certificate_chain { sha1, "..." } }, { certificate_chain { sha2-512, "..." } }, ... } How should a server behave if it receives a HashAlgorithm it doesn't support, for a CachedInformationType it does support? I suggest unsupported hashes should be ignored by servers. I think some guidance in the document is needed to make sure algorithm agility will work. In other words, after: Hash algorithm identifiers are provided by the RFC 5246 [RFC5246] HashAlgorithm registry. Compliant implementations MUST support sha1(2) as HashAlgorithm. add this sentence: Servers MUST ignore unsupported hash algorithm identifiers. This leads to the possibly surprising behaviour that if a sha1 value is not sent by the client, and the server only supports sha1, the extension will not be negotiated. But that is right, isn't it? /Simon > /Stefan > > > On 09-06-05 2:36 PM, "Simon Josefsson" wrote: > >> A minor discussion would be whether adding support for SHA-256/384/512 >> is worthwhile, but I don't feel strongly either way. From simon@josefsson.org Mon Jun 8 23:40:36 2009 Return-Path: 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 0E3203A6CD5 for ; Mon, 8 Jun 2009 23:40:36 -0700 (PDT) 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=[AWL=0.000, 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 w0AwfNDpLC9w for ; Mon, 8 Jun 2009 23:40:35 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id C69653A6BDE for ; Mon, 8 Jun 2009 23:40:34 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n596eZ1G026677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jun 2009 08:40:37 +0200 From: Simon Josefsson To: martin.rex@sap.com References: <87fxeerjv3.fsf@mocca.josefsson.org> <200906052055.n55KtrQ2024766@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090609:martin.rex@sap.com::xcAWX+WcpnG6Y/S/:pZM X-Hashcash: 1:22:090609:tls@ietf.org::0O5lkw74nGX4+5+X:Y+NQ Date: Tue, 09 Jun 2009 08:40:35 +0200 In-Reply-To: <200906052055.n55KtrQ2024766@fs4113.wdf.sap.corp> (Martin Rex's message of "Fri, 5 Jun 2009 22:55:53 +0200 (MEST)") Message-ID: <87k53lkizg.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 06:40:36 -0000 Martin Rex writes: > Simon Josefsson wrote: >> >> First, this paragraph: >> >> Servers that receive an extended client hello containing a >> "cached_information" extension, MAY indicate that they support one or >> more of the cached information objects by including an extension of >> type "cached_information" in the (extended) server hello, which SHALL >> contain at least one CachedObject received from the client. >> >> The intention here appears under-specified. What does it mean if the >> client sent two CachedObject's and the server just returned one of them? >> One plausible interpretation would be that the server did not support >> the hash/type-combination that were not returned. Enforcing that >> interpretation is needed to resolve my second concern. >> >> I suggest to add a sentence: >> >> The CachedObject's returned by the server MUST include the types the >> server supports and has accepted to replace with cached data. > > I don't know whether I correctly understand the suggestion > that you're making. But I'm very unhappy with one possible > interpretation that I see in your poposal. > > Having the TLS server indicate for which objects its TLS implementation > supports the caching _in_principle_ is fine with me. > > Requiring the server to already know the hash values of > parts the contents of future SSL handshake messages, specifically > the to-be-cached data at the time when composing the ServerHello > handshake message is something I would definitely not like. > > The impact on implementations of TLS should be as small as possible. > To me, a requirement for a TLS server to precompute hashes over > parts of future handshake messages during ServerHello looks like > a significant additional burden, and personally, I do not yet see > any benefit this might provide. Good point, but how would a client know whether a server replaced the cached information with a hash or not if there is no signaling whether this happened or not? /Simon From simon@josefsson.org Mon Jun 8 23:57:55 2009 Return-Path: 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 01EBB3A6909 for ; Mon, 8 Jun 2009 23:57:55 -0700 (PDT) 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=[AWL=0.000, 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 HXnMzuwE8c28 for ; Mon, 8 Jun 2009 23:57:53 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 8C43C3A68EC for ; Mon, 8 Jun 2009 23:57:53 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n596vqZB026958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jun 2009 08:57:54 +0200 From: Simon Josefsson To: Stefan Santesson References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090609:stefan@aaa-sec.com::+0XQmYxAOI8L3m91:D0A0 X-Hashcash: 1:22:090609:tls@ietf.org::WDVVuaRR6ol1v/q6:Hb15 X-Hashcash: 1:22:090609:martin.rex@sap.com::by/YvLOATB53V2mp:NZXt Date: Tue, 09 Jun 2009 08:57:53 +0200 In-Reply-To: (Stefan Santesson's message of "Sun, 07 Jun 2009 10:46:52 +0200") Message-ID: <87fxe9ki6m.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 06:57:55 -0000 Stefan Santesson writes: > I think I have to try to clarify this > > The client send a cached_information extension which contains a list of > CachedObject structures. > > Each ChachedObject element contains: > > - type identifier (CachedInformationType type) > - a list of hash values (CachedInformationHash hashes) > > Each CachedInformationHash contains: > > - Algorithm identifier (HashAlgorithm hash) > - Hash value (opaque hash_value) Right. > There are a number of issues that need to be specified or clarified in the > draft: > > 1) Is it allowed to send over multiple CachedObject elements containing the > same type identifier? > > Proposed answer = No (you can already include multiple hashes for each type) Agreed. There is a follow-on question here: Is it allowed to send over multiple CachedObject elements containing the same type identifier and same hash algorithm but different hash values? The options and consequences are: No: This is the simplest. In this case, I don't see a reason for the server to send back the same hash value the client sent -- so the Hash value field would be removed in the server response, to save some more space. Yes: This allows clients to send hashes for multiple variants of the cached information. For example, the client may have received two different server certificates in the past, and may want to offer caching of both. The Yes case seems complex but there could be use cases for it. If you didn't think of this, I'd prefer to disallow it. > 2) What should the server return in its server hello message for each > acceptable CachedObject? > > Alternative 1 = The CachedObject element, exactly as it was received by the > client (with all hashes) > > Alternative 2 = The CachedObject element, but only containing the > CachedInformationHash elements that is recognize and support. > > Proposed answer = Alternative 1 (This allows the server to say YES in > principle without analyzing the hash values at the time of Hello > exchange) I don't see any value in duplicating the hash values here though? > 3) Is the server REQUIRED to honor its support of a CachedObject by > replacing the identified handshake data with a received hash? > > Proposed answer = NO (for reasons raised by Martin) I understand Martin's concern, but how would a client know whether data was replaced or not? How would the client know which hash algorithm is used? > 4) What does the server send as replacement for the replaced handshake data? > > Proposed answer = One opaque hash_value (without hash type identifier) that > was received by the client, which MUST contain a valid hash over the > replaced data. I think we need to include the hash algorithm too. You cannot infer which hash algorithm is used based on the length only. I don't think it is reliable to optionally replace data. Hash values can be made to look like valid ASN.1, and the client would have to guess whether the server replaced the value or not. /Simon > > > Do you agree? > > /Stefan > > > > On 09-06-06 3:17 AM, "Stefan Santesson" wrote: > >> Martin, >> >> I liked Simon's suggestion as he expressed my original thought that the >> Server would know beforehand the hashes for acceptable information objects. >> >> However, what you suggest actually makes sense to me. >> >> I also found another minor error as the draft refer to hash_value (single >> hash) when I should refer to the "hashes" (multiple hash) element. >> >> We have to think through the concept of sending over multiple hashes and >> what the appropriate response from the server is. >> >> 1) The server accepts replacement in principle, but does not know at the >> time of sending the server hello if any of the hashes match. >> >> 2) The server accepts one or more hashes from the client hello (for one >> object type) and includes the hashes it accepts in the server hello >> >> 3) The server accepts one or more hashes from the client hello (for one >> object type) but includes only 1 (the preferred one) hash for that object >> type in the server hello. >> >> Once we can agree on this, I will update and submit a new version of the >> draft. >> >> /Stefan >> >> >> >> >> On 09-06-05 10:55 PM, "Martin Rex" wrote: >> >>> Simon Josefsson wrote: >>>> >>>> First, this paragraph: >>>> >>>> Servers that receive an extended client hello containing a >>>> "cached_information" extension, MAY indicate that they support one or >>>> more of the cached information objects by including an extension of >>>> type "cached_information" in the (extended) server hello, which SHALL >>>> contain at least one CachedObject received from the client. >>>> >>>> The intention here appears under-specified. What does it mean if the >>>> client sent two CachedObject's and the server just returned one of them? >>>> One plausible interpretation would be that the server did not support >>>> the hash/type-combination that were not returned. Enforcing that >>>> interpretation is needed to resolve my second concern. >>>> >>>> I suggest to add a sentence: >>>> >>>> The CachedObject's returned by the server MUST include the types the >>>> server supports and has accepted to replace with cached data. >>> >>> I don't know whether I correctly understand the suggestion >>> that you're making. But I'm very unhappy with one possible >>> interpretation that I see in your poposal. >>> >>> Having the TLS server indicate for which objects its TLS implementation >>> supports the caching _in_principle_ is fine with me. >>> >>> Requiring the server to already know the hash values of >>> parts the contents of future SSL handshake messages, specifically >>> the to-be-cached data at the time when composing the ServerHello >>> handshake message is something I would definitely not like. >>> >>> The impact on implementations of TLS should be as small as possible. >>> To me, a requirement for a TLS server to precompute hashes over >>> parts of future handshake messages during ServerHello looks like >>> a significant additional burden, and personally, I do not yet see >>> any benefit this might provide. >>> >>> >>> -Martin >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From simon@josefsson.org Tue Jun 9 00:02:51 2009 Return-Path: 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 E264A3A698D for ; Tue, 9 Jun 2009 00:02:51 -0700 (PDT) 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=[AWL=0.000, 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 yPhWtgtyOWRy for ; Tue, 9 Jun 2009 00:02:51 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 4E3753A683F for ; Tue, 9 Jun 2009 00:02:50 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5972eMO027099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jun 2009 09:02:44 +0200 From: Simon Josefsson To: Stefan Santesson References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090609:tls@ietf.org::MoLcP/rWJiw5Lc1q:9cao X-Hashcash: 1:22:090609:stefan@aaa-sec.com::2PxGjn/nxjZ4kUXE:O7da Date: Tue, 09 Jun 2009 09:02:40 +0200 In-Reply-To: (Stefan Santesson's message of "Thu, 04 Jun 2009 19:41:07 +0200") Message-ID: <87bpoxkhyn.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS wg Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 07:02:52 -0000 Another minor point, quoting the document: When CachedInformationType identifies certificate_chain, then hash_value MUST include at least one hash value calculated over the certificate_list element of a server side 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. And quoting RFC 5246 for the definitions of certificate_list and certificate_authorities: opaque ASN.1Cert<1..2^24-1>; struct { ASN.1Cert certificate_list<0..2^24-1>; } Certificate; ... 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; Q: Should the length bytes be included in the hash input or not? /Simon From sshen@huawei.com Tue Jun 9 02:09:26 2009 Return-Path: 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 705C228C161 for ; Tue, 9 Jun 2009 02:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.593 X-Spam-Level: * X-Spam-Status: No, score=1.593 tagged_above=-999 required=5 tests=[AWL=2.088, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 k5WiJ5eMELId for ; Tue, 9 Jun 2009 02:09:25 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 90D5128C12B for ; Tue, 9 Jun 2009 02:09:25 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKY00F7CRRWWM@szxga04-in.huawei.com> for TLS@ietf.org; Tue, 09 Jun 2009 17:02:20 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKY00I49RRW7O@szxga04-in.huawei.com> for TLS@ietf.org; Tue, 09 Jun 2009 17:02:20 +0800 (CST) Received: from s00102542 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKY00IP5RRV9I@szxml04-in.huawei.com> for TLS@ietf.org; Tue, 09 Jun 2009 17:02:20 +0800 (CST) Date: Tue, 09 Jun 2009 17:02:19 +0800 From: Sean Shen In-reply-to: <87vdn5kjm8.fsf@mocca.josefsson.org> To: 'Simon Josefsson' Message-id: <003a01c9e8e0$febb83f0$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acnoy3XaZhGo0pJKTqiT76bFQIFHAAAFGGHA Cc: TLS@ietf.org Subject: Re: [TLS] FWD: First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 09:09:26 -0000 > > Hi, Stefan, > > I support the idea and like the benefit of not transporting Certs. > > The drafts looks good and clear to me, except that I get some > > questions regarding the following part in section 4: > > > > Servers that receive an extended client hello containing a > > "cached_information" extension, MAY indicate that they > support one or > > more of the cached information objects by including an > extension of > > type "cached_information" in the (extended) server > hello, which SHALL > > contain at least one CachedObject received from the client. The > > CachedObject's returned by the server MUST include the types the > > server supports and has accepted to replace with a hash > of the cached > > data. > > > > It gives me impression that server's reply can include > items that is > > beyond cached items which clients provide. Is it possible > (or leagal) > > for clients to use those items which he did not mentioned but were > > indicated usable by server? > > For example clients provides items {A, B}, server replied {B, C}. > > B has been confirmed by both sides, C is confirmed only by > Server. If > > B and C are both acceptable, but the two negotiation base are not > > quite same, will there be a problem ? > > Not quite sure it would > > cause trouble or not though, but wondering whether it will. > > Good point. I don't see how that could work -- how would the > server know whether the client supported C? The client needs > to understand C in order to parse the handshake properly. Right, this is another reason that replying extra items beyond client's proposal is not a good idea. So I suggest that server should only reply with items chosen from client's proposal, the current wording in the draft does allow that happens. Sean From sshen@huawei.com Tue Jun 9 02:24:13 2009 Return-Path: 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 1B0AD3A6921 for ; Tue, 9 Jun 2009 02:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.176 X-Spam-Level: * X-Spam-Status: No, score=1.176 tagged_above=-999 required=5 tests=[AWL=1.671, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 JkuK-L79nCXO for ; Tue, 9 Jun 2009 02:24:12 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 336433A67F2 for ; Tue, 9 Jun 2009 02:24:12 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKY00640SHQKU@szxga04-in.huawei.com> for TLS@ietf.org; Tue, 09 Jun 2009 17:17:50 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKY005AFSHQKX@szxga04-in.huawei.com> for TLS@ietf.org; Tue, 09 Jun 2009 17:17:50 +0800 (CST) Received: from s00102542 ([10.111.12.128]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKY00LU7SHQW3@szxml06-in.huawei.com> for TLS@ietf.org; Tue, 09 Jun 2009 17:17:50 +0800 (CST) Date: Tue, 09 Jun 2009 17:17:49 +0800 From: Sean Shen In-reply-to: <003a01c9e8e0$febb83f0$800c6f0a@china.huawei.com> To: 'Sean Shen' , 'Simon Josefsson' Message-id: <003b01c9e8e3$293f6310$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acnoy3XaZhGo0pJKTqiT76bFQIFHAAAFGGHAAAC+aFA= Cc: TLS@ietf.org Subject: Re: [TLS] FWD: First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 09:24:13 -0000 sorry, made a mistake in previous message, I was trying to say: Right, this is another reason that replying extra items beyond client's proposal is not a good idea, the current wording in the draft does allow that happens. So I suggest that server should only reply with items chosen from client's proposal. Sean > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On > Behalf Of Sean Shen > Sent: Tuesday, June 09, 2009 5:02 PM > To: 'Simon Josefsson' > Cc: TLS@ietf.org > Subject: Re: [TLS] FWD: First TLS cached information draft posted > > > > > Hi, Stefan, > > > I support the idea and like the benefit of not transporting Certs. > > > The drafts looks good and clear to me, except that I get some > > > questions regarding the following part in section 4: > > > > > > Servers that receive an extended client hello containing a > > > "cached_information" extension, MAY indicate that they > > support one or > > > more of the cached information objects by including an > > extension of > > > type "cached_information" in the (extended) server > > hello, which SHALL > > > contain at least one CachedObject received from the client. The > > > CachedObject's returned by the server MUST include the > types the > > > server supports and has accepted to replace with a hash > > of the cached > > > data. > > > > > > It gives me impression that server's reply can include > > items that is > > > beyond cached items which clients provide. Is it possible > > (or leagal) > > > for clients to use those items which he did not mentioned > but were > > > indicated usable by server? > > > For example clients provides items {A, B}, server replied {B, C}. > > > B has been confirmed by both sides, C is confirmed only by > > Server. If > > > B and C are both acceptable, but the two negotiation base are not > > > quite same, will there be a problem ? > > > Not quite sure it would > > > cause trouble or not though, but wondering whether it will. > > > > Good point. I don't see how that could work -- how would > the server > > know whether the client supported C? The client needs to > understand C > > in order to parse the handshake properly. > > Right, this is another reason that replying extra items > beyond client's proposal is not a good idea. > So I suggest that server should only reply with items chosen > from client's proposal, the current wording in the draft does > allow that happens. > > Sean > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From Martin.Rex@sap.com Tue Jun 9 03:02:37 2009 Return-Path: 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 806C53A6A28 for ; Tue, 9 Jun 2009 03:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 H7S5x7iYQyZa for ; Tue, 9 Jun 2009 03:02:36 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 727223A67F2 for ; Tue, 9 Jun 2009 03:02:35 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n59A2dOQ007040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 12:02:39 +0200 (MEST) From: Martin Rex Message-Id: <200906091002.n59A2b5M019183@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Tue, 9 Jun 2009 12:02:37 +0200 (MEST) In-Reply-To: <87k53lkizg.fsf@mocca.josefsson.org> from "Simon Josefsson" at Jun 9, 9 08:40:35 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 10:02:37 -0000 Simon Josefsson wrote: > Martin Rex wrote: > > The impact on implementations of TLS should be as small as possible. > > To me, a requirement for a TLS server to precompute hashes over > > parts of future handshake messages during ServerHello looks like > > a significant additional burden, and personally, I do not yet see > > any benefit this might provide. > > Good point, but how would a client know whether a server replaced the > cached information with a hash or not if there is no signaling whether > this happened or not? The client knows which Hash it would find, if the server would sent the hash, so it could check for that. Even a collision of the hash and the original handshake data would not cause a problem with this "heuristical" determination. I'm wondering about the following: we should give a strong recommendation about the minimum size of an object in order for caching to make any sense at all, like >= 2x the size of the hash. At least 2x, because the hash appears (at least) twice in a full SSL handshake (ClientHello and the actual handshake message with the cached information). For a SSL session resume, the extension will create an unconditional burden, because the ClientHello extension would need to be present in every ClientHello, in order to actually save on the full handshake in case the server decides to require one (e.g. session expired on server side). Maybe the minimum size should be rather 3x hash size, considering the rest of the protocol overhead. -Martin From simon@josefsson.org Tue Jun 9 03:59:59 2009 Return-Path: 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 5E5323A6CBE for ; Tue, 9 Jun 2009 03:59:59 -0700 (PDT) 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=[AWL=0.000, 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 p4tDSYBRGr1C for ; Tue, 9 Jun 2009 03:59:58 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 23CDE3A6C73 for ; Tue, 9 Jun 2009 03:59:57 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-60.bredband.comhem.se [80.216.24.60]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n59Axqic000439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jun 2009 12:59:59 +0200 From: Simon Josefsson To: martin.rex@sap.com References: <87k53lkizg.fsf@mocca.josefsson.org> <200906091002.n59A2b5M019183@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090609:tls@ietf.org::7CPufywfXD/YBYAW:LIpn X-Hashcash: 1:22:090609:martin.rex@sap.com::9gp5qmjLs1oREoBX:MnLG Date: Tue, 09 Jun 2009 12:59:52 +0200 In-Reply-To: <200906091002.n59A2b5M019183@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 9 Jun 2009 12:02:37 +0200 (MEST)") Message-ID: <87ab4hisev.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 10:59:59 -0000 Martin Rex writes: > Simon Josefsson wrote: >> Martin Rex wrote: >> > The impact on implementations of TLS should be as small as possible. >> > To me, a requirement for a TLS server to precompute hashes over >> > parts of future handshake messages during ServerHello looks like >> > a significant additional burden, and personally, I do not yet see >> > any benefit this might provide. >> >> Good point, but how would a client know whether a server replaced the >> cached information with a hash or not if there is no signaling whether >> this happened or not? > > The client knows which Hash it would find, if the server would sent > the hash, so it could check for that. Even a collision of the > hash and the original handshake data would not cause a problem > with this "heuristical" determination. > > I'm wondering about the following: we should give a strong recommendation > about the minimum size of an object in order for caching to make any > sense at all, like >= 2x the size of the hash. > > At least 2x, because the hash appears (at least) twice in a full SSL > handshake (ClientHello and the actual handshake message with the > cached information). > > For a SSL session resume, the extension will create an unconditional > burden, because the ClientHello extension would need to be present > in every ClientHello, in order to actually save on the full handshake > in case the server decides to require one (e.g. session expired on > server side). > > Maybe the minimum size should be rather 3x hash size, considering > the rest of the protocol overhead. This seems like a good idea -- and it solves the problem in the client to identify whether the server replaced the data or not. If the minimum size is 3x hash size, the client can look at the length of the data. If it is longer than 3x hash size, it knows the server opted out from sending the hash. If it is shorter than 3x hash size, it knows the server actually did replace the data with a hash value. It seems wasteful that the same hash value is sent back and forth _three_ times during a handshake, and possibly that could be optimized. But that would add complexity. /Simon From Martin.Rex@sap.com Tue Jun 9 05:23:50 2009 Return-Path: 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 0C0683A659B for ; Tue, 9 Jun 2009 05:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 nwIVFRRVXUM2 for ; Tue, 9 Jun 2009 05:23:49 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id CDCD63A6E3D for ; Tue, 9 Jun 2009 05:23:48 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n59CNr2D025304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 14:23:53 +0200 (MEST) From: Martin Rex Message-Id: <200906091223.n59CNqov028494@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Tue, 9 Jun 2009 14:23:52 +0200 (MEST) In-Reply-To: <87ab4hisev.fsf@mocca.josefsson.org> from "Simon Josefsson" at Jun 9, 9 12:59:52 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 12:23:50 -0000 Simon Josefsson wrote: > > Martin Rex writes: > > >Simon Josefsson wrote: > >> > >> Good point, but how would a client know whether a server replaced the > >> cached information with a hash or not if there is no signaling whether > >> this happened or not? > > > > The client knows which Hash it would find, if the server would sent > > the hash, so it could check for that. Even a collision of the > > hash and the original handshake data would not cause a problem > > with this "heuristical" determination. > > > > I'm wondering about the following: we should give a strong recommendation > > about the minimum size of an object in order for caching to make any > > sense at all, like >= 2x the size of the hash. > > > > Maybe the minimum size should be rather 3x hash size, considering > > the rest of the protocol overhead. > > This seems like a good idea -- and it solves the problem in the client > to identify whether the server replaced the data or not. If the minimum > size is 3x hash size, the client can look at the length of the data. If > it is longer than 3x hash size, it knows the server opted out from > sending the hash. If it is shorter than 3x hash size, it knows the > server actually did replace the data with a hash value. Not quite. The caching extension is supposed to be generic, and the to-be-cached real data may in some situations be quite short or even the same size than the hash value (probably not for the server certificate caching, but maybe for the list of certification authorities in the certificate request message, which consists of distinguished names only, and there could be just one very short DName (or none at all with TLS v1.1+) > > It seems wasteful that the same hash value is sent back and forth > _three_ times during a handshake, and possibly that could be optimized. > But that would add complexity. There are several conceivable approaches, so we might want to weigh the pros and cons for them. - out-of-band signalling, i.e. in the Server-Hello extension (++) no ambiguity about what is sent, no matter what is acutually used as replacement in the encoded handshake message (---) would require server to pre-compute hashes over parts of future tls handshake messages when composing Server-Hello - in-band-signalling, i.e. a combination of the Server-Hello acknowledgement for principle support of caching a particular piece of information of the (full) SSL handshake plus a replacement tag that the client can recognize for the cached piece of information within the SSL handshake message in case the hash provided by the client matches the hash over the data that the server would normally send. (++) smaller impact on the overall architecture of the TLS implementation, because there is no requirement to precompute a hash over parts of a future tls handshake message (-) requires a sort-of heuristic determination whether the data encoded in a handshake message is real data or the replacement tag--be it a fixed short tag or the hash (pre-requisite: the client asserted the hash for cached information in ClientHello and the server acknowledged support for this in ServerHello) -Martin From simon@josefsson.org Tue Jun 9 06:41:32 2009 Return-Path: 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 1BBE63A6806 for ; Tue, 9 Jun 2009 06:41:32 -0700 (PDT) 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 zH1+7Hp66JDI for ; Tue, 9 Jun 2009 06:41:31 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id E79E73A659B for ; Tue, 9 Jun 2009 06:41:30 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-60.bredband.comhem.se [80.216.24.60]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n59DfRXN004037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jun 2009 15:41:34 +0200 From: Simon Josefsson To: martin.rex@sap.com References: <87ab4hisev.fsf@mocca.josefsson.org> <200906091223.n59CNqov028494@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090609:martin.rex@sap.com::8o9NlcPhAbYWy4Vg:EMJY X-Hashcash: 1:22:090609:tls@ietf.org::L/NjGcMnGviO1vW4:P6He Date: Tue, 09 Jun 2009 15:41:27 +0200 In-Reply-To: <200906091223.n59CNqov028494@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 9 Jun 2009 14:23:52 +0200 (MEST)") Message-ID: <87k53lh6d4.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:41:32 -0000 Martin Rex writes: > Simon Josefsson wrote: >> >> Martin Rex writes: >> >> >Simon Josefsson wrote: >> >> >> >> Good point, but how would a client know whether a server replaced the >> >> cached information with a hash or not if there is no signaling whether >> >> this happened or not? >> > >> > The client knows which Hash it would find, if the server would sent >> > the hash, so it could check for that. Even a collision of the >> > hash and the original handshake data would not cause a problem >> > with this "heuristical" determination. >> > >> > I'm wondering about the following: we should give a strong recommendation >> > about the minimum size of an object in order for caching to make any >> > sense at all, like >= 2x the size of the hash. >> > >> > Maybe the minimum size should be rather 3x hash size, considering >> > the rest of the protocol overhead. >> >> This seems like a good idea -- and it solves the problem in the client >> to identify whether the server replaced the data or not. If the minimum >> size is 3x hash size, the client can look at the length of the data. If >> it is longer than 3x hash size, it knows the server opted out from >> sending the hash. If it is shorter than 3x hash size, it knows the >> server actually did replace the data with a hash value. > > Not quite. > > The caching extension is supposed to be generic, and the to-be-cached > real data may in some situations be quite short or even the same size > than the hash value (probably not for the server certificate caching, > but maybe for the list of certification authorities in the certificate > request message, which consists of distinguished names only, and > there could be just one very short DName (or none at all with TLS v1.1+) Then why use the extension? The point of the extension, as I understood it, is to replace large data with a small hash of the same data. If the data is small, the extension doesn't serve any purpose and should not be used. That is why I liked your suggestion to limit the use of the extension when the data is larger than 3x hash size. /Simon From Martin.Rex@sap.com Tue Jun 9 06:47:33 2009 Return-Path: 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 797223A6806 for ; Tue, 9 Jun 2009 06:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 wtGTeOIb3aFk for ; Tue, 9 Jun 2009 06:47:32 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 53EC83A659B for ; Tue, 9 Jun 2009 06:47:32 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n59DlZ17010900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 15:47:35 +0200 (MEST) From: Martin Rex Message-Id: <200906091347.n59DlYva003622@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Tue, 9 Jun 2009 15:47:34 +0200 (MEST) In-Reply-To: <87fxe9ki6m.fsf@mocca.josefsson.org> from "Simon Josefsson" at Jun 9, 9 08:57:53 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:47:33 -0000 Simon Josefsson wrote: > > > 3) Is the server REQUIRED to honor its support of a CachedObject by > > replacing the identified handshake data with a received hash? > > > > Proposed answer = NO (for reasons raised by Martin) > > I understand Martin's concern, but how would a client know whether data > was replaced or not? How would the client know which hash algorithm is > used? The Server can reliably signal in the ServerHello extension whether it supports Caching for an object for which the Client asserted a Hash value in the ClientHello extension, and the Server ought to be able to decide upfront which Hash algorithms it supports. Allowing the client to supply different hashes for different incarnations of the same tls handshake data would significantly increase the protocol complexity. Suddenly, the hash values of different algorithms might refer to different cached data. I would suggest to limit the client to announce only one cached value (possibly with different hash algorithms, but then the server should not have to check each hash value for a mach, but only the hash algorithm selected by the server). It might be sensible for the client to manage cache entries based on several attributes, and in particular distuigish also by the "server name" as used in the TLS extension "Server name indication" in order to support TLS-compatible virtual hosting. > > > 4) What does the server send as replacement for the replaced handshake data? > > > > Proposed answer = One opaque hash_value (without hash type identifier) that > > was received by the client, which MUST contain a valid hash over the > > replaced data. > > I think we need to include the hash algorithm too. You cannot infer > which hash algorithm is used based on the length only. > > I don't think it is reliable to optionally replace data. Hash values > can be made to look like valid ASN.1, and the client would have to guess > whether the server replaced the value or not. The Server Hello Extension should indicate whether the server will try to use the caching extension, and which hash algorithm it is going to use (from those proposed by the client). So the "heuristic" of the client is to match the potentially cached data (length first, then data) against the one hash value that the client originally proposed in the ClientHelloExtension and that the server agreed to support in the ServerHelloExtension. Personally, I'm not concerned about a potential collision of the clients proposed hash with the real data that the server is going to send. Such a collision would not affect the data that the server is going to send, it could only affect how the client would interpret it (using the cached data instead of parsing the real data that looks like its proposed hash). What are possible alternatives? - Send other data that could be ambiguous in other scenarios - Send data in a specifically invalid fashion, i.e. a maximum-value length field that exceeds the outer container size. -Martin From Martin.Rex@sap.com Tue Jun 9 06:52:30 2009 Return-Path: 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 94FCB3A6856 for ; Tue, 9 Jun 2009 06:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 Yv4sCLaH9KeJ for ; Tue, 9 Jun 2009 06:52:29 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 92CD73A6819 for ; Tue, 9 Jun 2009 06:52:29 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n59DqYYW021001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 15:52:34 +0200 (MEST) From: Martin Rex Message-Id: <200906091352.n59DqX3N004203@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Tue, 9 Jun 2009 15:52:33 +0200 (MEST) In-Reply-To: <87k53lh6d4.fsf@mocca.josefsson.org> from "Simon Josefsson" at Jun 9, 9 03:41:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:52:30 -0000 Simon Josefsson wrote: > > > > Not quite. > > > > The caching extension is supposed to be generic, and the to-be-cached > > real data may in some situations be quite short or even the same size > > than the hash value (probably not for the server certificate caching, > > but maybe for the list of certification authorities in the certificate > > request message, which consists of distinguished names only, and > > there could be just one very short DName (or none at all with TLS v1.1+) > > Then why use the extension? The point of the extension, as I understood > it, is to replace large data with a small hash of the same data. If the > data is small, the extension doesn't serve any purpose and should not be > used. That is why I liked your suggestion to limit the use of the > extension when the data is larger than 3x hash size. Look at this: Server supports caching of certificate_authorities list and runs with a large list Client connects, caches the long list and announces the hash of the cached information on future reconnects Server configuration is updated, certificate_authorities list is cut down and now only contains one very short name. Client connects again (having still cached the previous long list), server indicates to support caching of that value in principle, but returns the real data since the hash proposed by the client no longer matches. Client should now realize that the short data is the new real data, should probably drop the cached value, and refrain from further caching of the short value. -Martin From simon@josefsson.org Tue Jun 9 06:55:47 2009 Return-Path: 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 E2DCD3A691E for ; Tue, 9 Jun 2009 06:55:47 -0700 (PDT) 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=[AWL=0.000, 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 Xjczp6ZjLElu for ; Tue, 9 Jun 2009 06:55:47 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id CB9AA3A687D for ; Tue, 9 Jun 2009 06:55:46 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-60.bredband.comhem.se [80.216.24.60]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n59Dtn5s004362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jun 2009 15:55:51 +0200 From: Simon Josefsson To: martin.rex@sap.com References: <87ab4hisev.fsf@mocca.josefsson.org> <200906091223.n59CNqov028494@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090609:tls@ietf.org::4sii1AIFEESvYu7U:0x9e X-Hashcash: 1:22:090609:martin.rex@sap.com::sjKkzwdaItZ4e3IA:pUVN Date: Tue, 09 Jun 2009 15:55:49 +0200 In-Reply-To: <200906091223.n59CNqov028494@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 9 Jun 2009 14:23:52 +0200 (MEST)") Message-ID: <87fxe9h5p6.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:55:48 -0000 Here is a modified idea. Replace the CachedInformationHash with this structure: struct { HashAlgorithm hash; uint32 datasize; /* NEW. Size of hashed data. MUST be >= 4 * hashsize(hash) */ opaque hash_value<0..255>; } CachedInformationHash; The server respond by indicating whether it supports cached data in principle, but defers until later in the handshake to decide whether to replace data or not. This addresses Martin's concern. Then add text to say that datasize MUST be >= 4 * hashsize(hash) where hashsize is the hash output size, i.e., 20 for SHA-1. Smaller objects cannot be cached with this extension. The server can decide, when constructing later handshake packets, whether to replace the generated data with a hash or not. Typically, the server would generate the data as normal. Then if the client provided a cache extension type for the object, it will compare a hash of the generated data with the hash provided by the client. If they match, it will send the CachedInformationHash value instead of the generated data. The client parses the response, and can by looking at the size of each object decide whether it is a hash or real data. This runs into a problem if the server instead of returning a hash returned data that was considerably smaller than the value cached by the client. The client could then be confused whether the returned data is real data or a hash value. A type-specific tag could be constructed here -- for both certificate_list and certificate_authorities it could be some invalid ASN.1 followed by the CachedInformationHash. This is a compromise, but it seems difficult to solve both Martin's concern and my concern that clients needs to reliably be able to decode incoming data. Better ideas welcome. /Simon From simon@josefsson.org Tue Jun 9 07:00:20 2009 Return-Path: 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 C2E8D3A691E for ; Tue, 9 Jun 2009 07:00:20 -0700 (PDT) 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 dn56oh9cRaqY for ; Tue, 9 Jun 2009 07:00:20 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 9D8FA3A6819 for ; Tue, 9 Jun 2009 07:00:19 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-60.bredband.comhem.se [80.216.24.60]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n59E0Lmp004450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jun 2009 16:00:23 +0200 From: Simon Josefsson To: martin.rex@sap.com References: <200906091352.n59DqX3N004203@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090609:martin.rex@sap.com::+7R75t5+g2Ih0qJR:34+I X-Hashcash: 1:22:090609:tls@ietf.org::ZPTaZxk2qZthTQbd:DvQ1 Date: Tue, 09 Jun 2009 16:00:21 +0200 In-Reply-To: <200906091352.n59DqX3N004203@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 9 Jun 2009 15:52:33 +0200 (MEST)") Message-ID: <87bpoxh5hm.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 14:00:20 -0000 Martin Rex writes: > Simon Josefsson wrote: >> > >> > Not quite. >> > >> > The caching extension is supposed to be generic, and the to-be-cached >> > real data may in some situations be quite short or even the same size >> > than the hash value (probably not for the server certificate caching, >> > but maybe for the list of certification authorities in the certificate >> > request message, which consists of distinguished names only, and >> > there could be just one very short DName (or none at all with TLS v1.1+) >> >> Then why use the extension? The point of the extension, as I understood >> it, is to replace large data with a small hash of the same data. If the >> data is small, the extension doesn't serve any purpose and should not be >> used. That is why I liked your suggestion to limit the use of the >> extension when the data is larger than 3x hash size. > > Look at this: > > Server supports caching of certificate_authorities list and runs with > a large list > > Client connects, caches the long list and announces the hash of the > cached information on future reconnects > > Server configuration is updated, certificate_authorities list > is cut down and now only contains one very short name. > > Client connects again (having still cached the previous long list), > server indicates to support caching of that value in principle, > but returns the real data since the hash proposed by the client > no longer matches. > > Client should now realize that the short data is the new real > data, should probably drop the cached value, and refrain from > further caching of the short value. Right. That is how I think it should work as well. I believe that adding a limit of 4x hash size (or similar) is still useful, though, since it would be pointless for the client in your example to update its cached hash with a hash of the new string, and send that hash in the future. Doing so would result in a handshake that is potentially _larger_ than if the cached data were sent. /Simon From simon@josefsson.org Tue Jun 9 07:19:25 2009 Return-Path: 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 3F4473A6A51 for ; Tue, 9 Jun 2009 07:19:25 -0700 (PDT) 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 ZSDWbauTl8Yj for ; Tue, 9 Jun 2009 07:19:24 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 2C5A03A6996 for ; Tue, 9 Jun 2009 07:19:23 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-60.bredband.comhem.se [80.216.24.60]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n59EJQKC004785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jun 2009 16:19:28 +0200 From: Simon Josefsson To: martin.rex@sap.com References: <87fxe9ki6m.fsf@mocca.josefsson.org> <200906091347.n59DlYva003622@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090609:martin.rex@sap.com::N7KqrLrrppUeIr5R:N4g X-Hashcash: 1:22:090609:tls@ietf.org::JcoQ+wWcjrgvYoyp:KMQH Date: Tue, 09 Jun 2009 16:19:26 +0200 In-Reply-To: <200906091347.n59DlYva003622@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 9 Jun 2009 15:47:34 +0200 (MEST)") Message-ID: <87ws7lfq1d.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 14:19:25 -0000 Martin Rex writes: > It might be sensible for the client to manage cache entries based > on several attributes, and in particular distuigish also by the > "server name" as used in the TLS extension "Server name indication" > in order to support TLS-compatible virtual hosting. That is a good point, and it would help implementers to make this explicit. Stefan, how about adding a sentence to explain this? After this paragraph Clients MAY include an extension of type "cached_information" in the (extended) client hello, which SHALL contain at least one CachedObject as specified in section 2. you could add 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. If XML source is available, I could send you a patch. ;) Thanks, /Simon From root@core3.amsl.com Tue Jun 9 14:30:02 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 211553A6DE6; Tue, 9 Jun 2009 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090609213002.211553A6DE6@core3.amsl.com> Date: Tue, 9 Jun 2009 14:30:02 -0700 (PDT) Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-cached-info-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 21:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Cached Information Extension Author(s) : S. Santesson, Q. Dang Filename : draft-ietf-tls-cached-info-00.txt Pages : 5 Date : 2009-6-5 This document defines a Transport Layer Security (TLS) extension for cached information. This extension allows the TLS client to inform a server of cached information from previous TLS sessions, allowing the server to omit sending cached static information to the client during the TLS handshake protocol exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-cached-info-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-cached-info-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-6-9141949.I-D@ietf.org> --NextPart-- From huangmin123@huaweisymantec.com Tue Jun 9 23:57:01 2009 Return-Path: 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 616F53A6A15 for ; Tue, 9 Jun 2009 23:57:01 -0700 (PDT) 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 CHVnmZz3aFDb for ; Tue, 9 Jun 2009 23:57:00 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 6A3F33A659C for ; Tue, 9 Jun 2009 23:57:00 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KL00085CGN17R10@hstga02-in.huaweisymantec.com> for tls@ietf.org; Wed, 10 Jun 2009 14:57:01 +0800 (CST) Received: from h00104745 ([10.27.154.144]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KL000CBIGMXQI10@hstml01-in.huaweisymantec.com> for tls@ietf.org; Wed, 10 Jun 2009 14:57:01 +0800 (CST) From: Min Huang To: stefan@aaa-sec.com Date: Wed, 10 Jun 2009 14:56:57 +0800 Message-id: <001801c9e998$a58b4b40$909a1b0a@china.huawei.com> X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcnpmKU3A6jU6q9xQxOJfsECPeRUeQ== X-Mailman-Approved-At: Wed, 10 Jun 2009 06:20:29 -0700 Cc: tls@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 06:57:01 -0000 Hi, Stefan You said: "1) Is it allowed to send over multiple CachedObject elements containing the same type identifier? Proposed answer = No (you can already include multiple hashes for each type)" It means that the number of the cached certificate is one or it means the hash values of all cached certificates are contained in one CachedObject of the same type? regards, Min >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think I have to try to clarify this The client send a cached_information extension which contains a list of CachedObject structures. Each ChachedObject element contains: - type identifier (CachedInformationType type) - a list of hash values (CachedInformationHash hashes) Each CachedInformationHash contains: - Algorithm identifier (HashAlgorithm hash) - Hash value (opaque hash_value) There are a number of issues that need to be specified or clarified in the draft: 1) Is it allowed to send over multiple CachedObject elements containing the same type identifier? Proposed answer = No (you can already include multiple hashes for each type) 2) What should the server return in its server hello message for each acceptable CachedObject? Alternative 1 = The CachedObject element, exactly as it was received by the client (with all hashes) Alternative 2 = The CachedObject element, but only containing the CachedInformationHash elements that is recognize and support. Proposed answer = Alternative 1 (This allows the server to say YES in principle without analyzing the hash values at the time of Hello exchange) 3) Is the server REQUIRED to honor its support of a CachedObject by replacing the identified handshake data with a received hash? Proposed answer = NO (for reasons raised by Martin) 4) What does the server send as replacement for the replaced handshake data? Proposed answer = One opaque hash_value (without hash type identifier) that was received by the client, which MUST contain a valid hash over the replaced data. Do you agree? /Stefan From huangmin123@huaweisymantec.com Tue Jun 9 23:59:42 2009 Return-Path: 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 EAA233A6933 for ; Tue, 9 Jun 2009 23:59:42 -0700 (PDT) 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 pGBZGd3KQzMg for ; Tue, 9 Jun 2009 23:59:42 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id D8F8F3A659C for ; Tue, 9 Jun 2009 23:59:41 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KL00086QGRH7R10@hstga02-in.huaweisymantec.com> for tls@ietf.org; Wed, 10 Jun 2009 14:59:41 +0800 (CST) Received: from h00104745 ([10.27.154.144]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KL000CGBGREES10@hstml01-in.huaweisymantec.com> for tls@ietf.org; Wed, 10 Jun 2009 14:59:41 +0800 (CST) From: Min Huang To: simon@josefsson.org Date: Wed, 10 Jun 2009 14:59:38 +0800 Message-id: <001901c9e999$05678bf0$909a1b0a@china.huawei.com> X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcnpmQUPyeIL+L8CQ8a08xgkj0dS+w== X-Mailman-Approved-At: Wed, 10 Jun 2009 06:20:29 -0700 Cc: tls@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 06:59:43 -0000 Hi,Simon This "heuristic" determination works well in most scenarioes, but the client still be confused in some specific cases. I think adding a type-specific tag as you mentioned is a doable method, and it can solve the problems by now. And if we will construct a type-specific tag, the new "datasize" field in CachedInformationHash is still necessary? It seems not necessary any more. It can be a policy conformed by the client when caching data or sending a CachedObject. regards, Min >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simon wrote: Here is a modified idea. Replace the CachedInformationHash with this structure: struct { HashAlgorithm hash; uint32 datasize; /* NEW. Size of hashed data. MUST be >= 4 * hashsize(hash) */ opaque hash_value<0..255>; } CachedInformationHash; The server respond by indicating whether it supports cached data in principle, but defers until later in the handshake to decide whether to replace data or not. This addresses Martin's concern. Then add text to say that datasize MUST be >= 4 * hashsize(hash) where hashsize is the hash output size, i.e., 20 for SHA-1. Smaller objects cannot be cached with this extension. The server can decide, when constructing later handshake packets, whether to replace the generated data with a hash or not. Typically, the server would generate the data as normal. Then if the client provided a cache extension type for the object, it will compare a hash of the generated data with the hash provided by the client. If they match, it will send the CachedInformationHash value instead of the generated data. The client parses the response, and can by looking at the size of each object decide whether it is a hash or real data. This runs into a problem if the server instead of returning a hash returned data that was considerably smaller than the value cached by the client. The client could then be confused whether the returned data is real data or a hash value. A type-specific tag could be constructed here -- for both certificate_list and certificate_authorities it could be some invalid ASN.1 followed by the CachedInformationHash. This is a compromise, but it seems difficult to solve both Martin's concern and my concern that clients needs to reliably be able to decode incoming data. Better ideas welcome. /Simon From simon@josefsson.org Wed Jun 10 09:02:13 2009 Return-Path: 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 1BA3D3A6A02 for ; Wed, 10 Jun 2009 09:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_25=0.6] 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 fNddDVScntqa for ; Wed, 10 Jun 2009 09:02:12 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 0092A3A6831 for ; Wed, 10 Jun 2009 09:02:11 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-60.bredband.comhem.se [80.216.24.60]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5AG21FE010283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 10 Jun 2009 18:02:03 +0200 From: Simon Josefsson To: Min Huang References: <001901c9e999$05678bf0$909a1b0a@china.huawei.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090610:tls@ietf.org::tbKi6xhW+E6gw7+O:iGe X-Hashcash: 1:22:090610:huangmin123@huaweisymantec.com::jvOqNz1VH2/lVyT6:8NYe Date: Wed, 10 Jun 2009 18:02:00 +0200 In-Reply-To: <001901c9e999$05678bf0$909a1b0a@china.huawei.com> (Min Huang's message of "Wed, 10 Jun 2009 14:59:38 +0800") Message-ID: <87bpowaxhj.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 16:02:13 -0000 Min Huang writes: > Hi,Simon > > This "heuristic" determination works well in most scenarioes, > but the client still be confused in some specific cases. Hi. Yes. I don't like TLS implementations playing guessing games on the intended interpretation of received data, though, and that is my primary concern with this document right now. I'm wondering how other implementers feel about this, is it acceptable? > I think adding a type-specific tag as you mentioned is a doable > method, and it can solve the problems by now. > > And if we will construct a type-specific tag, the new "datasize" > field in CachedInformationHash is still necessary? It seems not > necessary any more. It can be a policy conformed by the client > when caching data or sending a CachedObject. Right. /Simon From Martin.Rex@sap.com Wed Jun 10 11:40:44 2009 Return-Path: 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 11F5B3A6CA9 for ; Wed, 10 Jun 2009 11:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 F28uTSlkbMCs for ; Wed, 10 Jun 2009 11:40:43 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 865533A6A7A for ; Wed, 10 Jun 2009 11:40:40 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n5AIed1M001149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 20:40:39 +0200 (MEST) From: Martin Rex Message-Id: <200906101840.n5AIecJE020341@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Wed, 10 Jun 2009 20:40:38 +0200 (MEST) In-Reply-To: <87bpowaxhj.fsf@mocca.josefsson.org> from "Simon Josefsson" at Jun 10, 9 06:02:00 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: huangmin123@huaweisymantec.com, tls@ietf.org Subject: Re: [TLS] First TLS cached information draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 18:40:44 -0000 Simon, Simon Josefsson wrote: > > Min Huang writes: > > > This "heuristic" determination works well in most scenarioes, > > but the client still be confused in some specific cases. > > Hi. Yes. I don't like TLS implementations playing guessing games on > the intended interpretation of received data, though, and that is my > primary concern with this document right now. I'm wondering how other > implementers feel about this, is it acceptable? What you could do, is to unconditionally use an additional framing for that being-cached parts of the TLS handshake messages for for which the Client requested caching in the ClientHelloExtension and and the Server acknowledged caching support in the ServerHelloExtension. (I'm not really accustomed to TLS spec language, so please apply common sense / corrections yourself): enum { original_data(1), hash_over_original_data(2), omitted_hash_over_original_data(3), original_data_and_suggestion_to_not_cache(4), (255) } CacheControlContentType; struct { CacheControlContentType type; opaque content<0..2^16-1>; } CacheControlContent; ...and drop the things that are not needed (but mentioned for completeness) This approach would unconditionally change the (affected) PDU if caching is negotiated but hashes do not match (as well). It facilitates to omit the actual hash value at this point in a non-ambiguous fashion (the hash should be part of the handshake once, but having it three times looks like waste). -Martin From simon@josefsson.org Wed Jun 10 14:04:15 2009 Return-Path: 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 432733A6BD3 for ; Wed, 10 Jun 2009 14:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 DwgiTXvYNKPL for ; Wed, 10 Jun 2009 14:04:14 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 1D6BE3A6AFE for ; Wed, 10 Jun 2009 14:04:13 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-60.bredband.comhem.se [80.216.24.60]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5AL4GWu017057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 10 Jun 2009 23:04:18 +0200 From: Simon Josefsson To: martin.rex@sap.com References: <87bpowaxhj.fsf@mocca.josefsson.org> <200906101840.n5AIecJE020341@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090610:tls@ietf.org::SZE0+BLOx3YhKx2g:7xi5 X-Hashcash: 1:22:090610:huangmin123@huaweisymantec.com::gbQGGIF5DgoBcgwi:8zeZ X-Hashcash: 1:22:090610:martin.rex@sap.com::VhoI9hrIgxllftxo:eCzu Date: Wed, 10 Jun 2009 23:04:15 +0200 In-Reply-To: <200906101840.n5AIecJE020341@fs4113.wdf.sap.corp> (Martin Rex's message of "Wed, 10 Jun 2009 20:40:38 +0200 (MEST)") Message-ID: <87hbynajhs.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 21:04:15 -0000 Martin Rex writes: > What you could do, is to unconditionally use an additional framing > for that being-cached parts of the TLS handshake messages for > for which the Client requested caching in the ClientHelloExtension > and and the Server acknowledged caching support in the > ServerHelloExtension. > > (I'm not really accustomed to TLS spec language, so please > apply common sense / corrections yourself): > > enum { > original_data(1), > hash_over_original_data(2), > omitted_hash_over_original_data(3), > original_data_and_suggestion_to_not_cache(4), > (255) > } CacheControlContentType; > > struct { > CacheControlContentType type; > opaque content<0..2^16-1>; > } CacheControlContent; > > > ...and drop the things that are not needed (but mentioned for completeness) > > > This approach would unconditionally change the (affected) PDU if caching is > negotiated but hashes do not match (as well). It facilitates to omit > the actual hash value at this point in a non-ambiguous fashion > (the hash should be part of the handshake once, but having it > three times looks like waste). I like this approach, it addresses both your and my original concerns. Stefan, what do you think? The resulting protocol is more complex with the above, but given that the original proposal is unreliable, I think the complexity is warranted here. /Simon From stefan@aaa-sec.com Thu Jun 11 14:32:32 2009 Return-Path: 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 66F693A6BB2 for ; Thu, 11 Jun 2009 14:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 Gj2bK2ILlUJB for ; Thu, 11 Jun 2009 14:32:30 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id D06783A6AF2 for ; Thu, 11 Jun 2009 14:32:28 -0700 (PDT) Received: (qmail 41130 invoked from network); 11 Jun 2009 21:32:39 -0000 Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 11 Jun 2009 21:32:38 -0000 Received: (qmail 29156 invoked from network); 11 Jun 2009 21:32:28 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Jun 2009 21:32:28 -0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 11 Jun 2009 23:32:28 +0200 From: Stefan Santesson To: Simon Josefsson , Message-ID: Thread-Topic: [TLS] First TLS cached information draft posted Thread-Index: Acnq3B5e96I5mdVVPUGV2jqDzvKtdg== In-Reply-To: <87hbynajhs.fsf@mocca.josefsson.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 21:32:32 -0000 Thanks for all the analysis and proposals. Unfortunately I have been on constant travel and meetings since Monday morning and it is not over until tomorrow night when I get home again. I will go through this more carefully then and get back to you no later than Monday. /Stefan On 09-06-10 11:04 PM, "Simon Josefsson" wrote: > Martin Rex writes: > >> What you could do, is to unconditionally use an additional framing >> for that being-cached parts of the TLS handshake messages for >> for which the Client requested caching in the ClientHelloExtension >> and and the Server acknowledged caching support in the >> ServerHelloExtension. >> >> (I'm not really accustomed to TLS spec language, so please >> apply common sense / corrections yourself): >> >> enum { >> original_data(1), >> hash_over_original_data(2), >> omitted_hash_over_original_data(3), >> original_data_and_suggestion_to_not_cache(4), >> (255) >> } CacheControlContentType; >> >> struct { >> CacheControlContentType type; >> opaque content<0..2^16-1>; >> } CacheControlContent; >> >> >> ...and drop the things that are not needed (but mentioned for completeness) >> >> >> This approach would unconditionally change the (affected) PDU if caching is >> negotiated but hashes do not match (as well). It facilitates to omit >> the actual hash value at this point in a non-ambiguous fashion >> (the hash should be part of the handshake once, but having it >> three times looks like waste). > > I like this approach, it addresses both your and my original concerns. > Stefan, what do you think? > > The resulting protocol is more complex with the above, but given that > the original proposal is unreliable, I think the complexity is warranted > here. > > /Simon > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From stefan@aaa-sec.com Tue Jun 16 07:59:05 2009 Return-Path: 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 276353A6A5E for ; Tue, 16 Jun 2009 07:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 4MZN0gsaOf4N for ; Tue, 16 Jun 2009 07:59:04 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 737563A6B6A for ; Tue, 16 Jun 2009 07:59:01 -0700 (PDT) Received: (qmail 22893 invoked from network); 16 Jun 2009 14:58:03 -0000 Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Jun 2009 14:58:03 -0000 Received: (qmail 79853 invoked from network); 16 Jun 2009 14:57:57 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 16 Jun 2009 14:57:57 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 16 Jun 2009 16:57:53 +0200 From: Stefan Santesson To: Simon Josefsson , Message-ID: Thread-Topic: [TLS] First TLS cached information draft posted Thread-Index: AcnuktMJCk5cfk/uv0y6UlzsicIQUg== In-Reply-To: <87hbynajhs.fsf@mocca.josefsson.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 14:59:05 -0000 Hi, I have now carefully read through this thread and spent some time thinking of it. I don't like the extra complexity of the proposed structure and I fail to see the problem of recognizing the hash as replacement of data. First of all, the worse case scenario if everything fails miserably and client mistake a hash for real data or the other way around, is a failed handshake. This is followed by a normal handshake where the client will reset it's cash for that server. This safe fallback allows us to accept reasonable risk of failure. Now, how hard is it to recognize a hash as replacement for cashed data and what is the risk of collision? In my world this is not hard at all. The hash code is a unique identification key, provided by the client. If these bits appear where the cached data was supposed to appear, it is a clean replacement. This is not hard to detect and risk of collision is negligible. It is totally irrelevant if the hash in theory can take the form of legal ASN.1, XML or anything. We know where the bits start in the handshake protocol, the hash bits was further chosen by the client and if the server or MitM tries to change them, it will only result in a failed handshake. In the sum of all, I would like to keep the current protocol syntax. /Stefan On 09-06-10 11:04 PM, "Simon Josefsson" wrote: > Martin Rex writes: > >> What you could do, is to unconditionally use an additional framing >> for that being-cached parts of the TLS handshake messages for >> for which the Client requested caching in the ClientHelloExtension >> and and the Server acknowledged caching support in the >> ServerHelloExtension. >> >> (I'm not really accustomed to TLS spec language, so please >> apply common sense / corrections yourself): >> >> enum { >> original_data(1), >> hash_over_original_data(2), >> omitted_hash_over_original_data(3), >> original_data_and_suggestion_to_not_cache(4), >> (255) >> } CacheControlContentType; >> >> struct { >> CacheControlContentType type; >> opaque content<0..2^16-1>; >> } CacheControlContent; >> >> >> ...and drop the things that are not needed (but mentioned for completeness) >> >> >> This approach would unconditionally change the (affected) PDU if caching is >> negotiated but hashes do not match (as well). It facilitates to omit >> the actual hash value at this point in a non-ambiguous fashion >> (the hash should be part of the handshake once, but having it >> three times looks like waste). > > I like this approach, it addresses both your and my original concerns. > Stefan, what do you think? > > The resulting protocol is more complex with the above, but given that > the original proposal is unreliable, I think the complexity is warranted > here. > > /Simon > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From stefan@aaa-sec.com Tue Jun 16 08:01:40 2009 Return-Path: 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 2D7843A6B97 for ; Tue, 16 Jun 2009 08:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 Lp9NdKKYR14d for ; Tue, 16 Jun 2009 08:01:39 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 04DE13A6B99 for ; Tue, 16 Jun 2009 08:01:38 -0700 (PDT) Received: (qmail 31213 invoked from network); 16 Jun 2009 14:59:51 -0000 Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Jun 2009 14:59:51 -0000 Received: (qmail 87352 invoked from network); 16 Jun 2009 14:59:45 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 16 Jun 2009 14:59:45 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 16 Jun 2009 16:59:44 +0200 From: Stefan Santesson To: Simon Josefsson , Message-ID: Thread-Topic: [TLS] First TLS cached information draft posted Thread-Index: AcnukxUybO+3oQBRnU6tn6RqGniNxg== In-Reply-To: <87ws7lfq1d.fsf@mocca.josefsson.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: TLS@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 15:01:40 -0000 Simon, This is a good suggestion. I have added this text in the edit pool of next version. Unfortunately I'm an nroff hacker :) /Stefan On 09-06-09 4:19 PM, "Simon Josefsson" wrote: > Martin Rex writes: > >> It might be sensible for the client to manage cache entries based >> on several attributes, and in particular distuigish also by the >> "server name" as used in the TLS extension "Server name indication" >> in order to support TLS-compatible virtual hosting. > > That is a good point, and it would help implementers to make this > explicit. Stefan, how about adding a sentence to explain this? After > this paragraph > > Clients MAY include an extension of type "cached_information" in the > (extended) client hello, which SHALL contain at least one > CachedObject as specified in section 2. > > you could add > > 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. > > If XML source is available, I could send you a patch. ;) > > Thanks, > /Simon > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From stefan@aaa-sec.com Tue Jun 16 08:11:15 2009 Return-Path: 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 522FC3A6D8C for ; Tue, 16 Jun 2009 08:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 rAFSRILBib7q for ; Tue, 16 Jun 2009 08:11:14 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 056383A6D69 for ; Tue, 16 Jun 2009 08:11:13 -0700 (PDT) Received: (qmail 74325 invoked from network); 16 Jun 2009 15:09:58 -0000 Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Jun 2009 15:09:58 -0000 Received: (qmail 29385 invoked from network); 16 Jun 2009 15:09:52 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 16 Jun 2009 15:09:52 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 16 Jun 2009 17:09:52 +0200 From: Stefan Santesson To: Min Huang Message-ID: Thread-Topic: [TLS] First TLS cached information draft posted Thread-Index: AcnpmKU3A6jU6q9xQxOJfsECPeRUeQE+9phM In-Reply-To: <001801c9e998$a58b4b40$909a1b0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 15:11:15 -0000 Ming and Simon, As you both seems to have misunderstood what I intended to say here. What I currently think is the correct way is to include just one CachedObject structure for each cached information type (e.g. One for certificate data and one for CA names). This CachedObject stucture may contain any number of hashes. This might be hashes using different algorithms over the same object or it may be hashes of the same kind over different objects (e.g. multiple acceptble certs). It is just an unordered list of hashes. The server now takes the data it intended to send. And compute the hash over that data with as many algorithms it can out of the algorithms used by the client. If one of the received hashes matches one of the generated hashes, the match is accepted and the server will return one of the matching hashes as acceptance of the cache (data replacement). This is at least how it was intended in the current draft. This is to me still the simplest, cleanest and easiest approach. /Stefan On 09-06-10 8:56 AM, "Min Huang" wrote: > Hi, Stefan > > You said: > "1) Is it allowed to send over multiple CachedObject elements > containing the same type identifier? > Proposed answer = No (you can already include multiple hashes > for each type)" > > It means that the number of the cached certificate is one or > it means the hash values of all cached certificates are contained > in one CachedObject of the same type? > > > regards, > Min > > > > >>>>>>>>>>>> > > I think I have to try to clarify this > > The client send a cached_information extension which contains a list of > CachedObject structures. > > Each ChachedObject element contains: > > - type identifier (CachedInformationType type) > - a list of hash values (CachedInformationHash hashes) > > Each CachedInformationHash contains: > > - Algorithm identifier (HashAlgorithm hash) > - Hash value (opaque hash_value) > > > > There are a number of issues that need to be specified or clarified in the > draft: > > 1) Is it allowed to send over multiple CachedObject elements containing the > same type identifier? > > Proposed answer = No (you can already include multiple hashes for each type) > > > 2) What should the server return in its server hello message for each > acceptable CachedObject? > > Alternative 1 = The CachedObject element, exactly as it was received by the > client (with all hashes) > > Alternative 2 = The CachedObject element, but only containing the > CachedInformationHash elements that is recognize and support. > > Proposed answer = Alternative 1 (This allows the server to say YES in > principle without analyzing the hash values at the time of Hello exchange) > > > 3) Is the server REQUIRED to honor its support of a CachedObject by > replacing the identified handshake data with a received hash? > > Proposed answer = NO (for reasons raised by Martin) > > > 4) What does the server send as replacement for the replaced handshake data? > > Proposed answer = One opaque hash_value (without hash type identifier) that > was received by the client, which MUST contain a valid hash over the > replaced data. > > > > Do you agree? > > /Stefan > > > From Martin.Rex@sap.com Tue Jun 16 08:29:22 2009 Return-Path: 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 D237D3A6AFF for ; Tue, 16 Jun 2009 08:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 7IqnRCGZPht7 for ; Tue, 16 Jun 2009 08:29:22 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id CAC283A691F for ; Tue, 16 Jun 2009 08:29:21 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n5GFT1Il016501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 17:29:01 +0200 (MEST) From: Martin Rex Message-Id: <200906161529.n5GFT0iP007243@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Tue, 16 Jun 2009 17:29:00 +0200 (MEST) In-Reply-To: from "Stefan Santesson" at Jun 16, 9 05:09:52 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: huangmin123@huaweisymantec.com, tls@ietf.org Subject: Re: [TLS] First TLS cached information draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 15:29:22 -0000 Stefan Santesson wrote: > > This CachedObject stucture may contain any number of hashes. This might be > hashes using different algorithms over the same object or it may be hashes > of the same kind over different objects (e.g. multiple acceptble certs). It > is just an unordered list of hashes. > > The server now takes the data it intended to send. And compute the hash over > that data with as many algorithms it can out of the algorithms used by the > client. If one of the received hashes matches one of the generated hashes, > the match is accepted and the server will return one of the matching hashes > as acceptance of the cache (data replacement). To me, this sounds more complex that I think it should be. I think the server should neither have to compute and neither have to check the hash values for all hash algorithms for which the client sent hashes. (which implies that the client has to send hash values consistently for all items and all hash algorithms that it wants to offer. The server should reply in the ServerHello extension for which items and which hash algorithm (of those poposed by the client) it supports substituting the real data with the replacement (the hash value in the current proposal). The server should not have to compute and compare multiple hash values over the real value when composing the handshake message affected by the diet, and neither should the client have to compare the substituted value to the hash values of more than one hash algorithm (when the client proposed multiple values for the same item with different hash algs. -Martin From Martin.Rex@sap.com Tue Jun 16 08:55:12 2009 Return-Path: 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 82E623A6D7F for ; Tue, 16 Jun 2009 08:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 DY0IlOUr8GVv for ; Tue, 16 Jun 2009 08:55:11 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 6F9B43A6915 for ; Tue, 16 Jun 2009 08:55:11 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n5GFsrBe015527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 17:54:53 +0200 (MEST) From: Martin Rex Message-Id: <200906161554.n5GFsqxv008514@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Tue, 16 Jun 2009 17:54:52 +0200 (MEST) In-Reply-To: from "Stefan Santesson" at Jun 16, 9 04:57:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: simon@josefsson.org, tls@ietf.org Subject: Re: [TLS] First TLS cached information draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 15:55:12 -0000 Stefan, Stefan Santesson wrote: > > I don't like the extra complexity of the proposed structure and I fail to > see the problem of recognizing the hash as replacement of data. > > First of all, the worse case scenario if everything fails miserably and > client mistake a hash for real data or the other way around, is a failed > handshake. > > This is followed by a normal handshake where the client will reset it's cash > for that server. > > This safe fallback allows us to accept reasonable risk of failure. > > Now, how hard is it to recognize a hash as replacement for cashed data and > what is the risk of collision? I agree that probability of an accidental exact match (length and value) between a hash value over previous real data and the representation of new real data after a config change of the server is EXTREMELY low. Personally, I it consider it negligable. I do not agree with the reasoning about the recovery -- a requirement to close a communcation channel entirely and restart from scratch is something that is likely going to break a lot of apps (I wish it did not, but unfortunately, it does). Designing the protocol in a robust fashion so that there is no abiguitiy, and unnecessary risks of failure are avoided, is usually a sensible thing to do. I personally do not think we have such a risk here, it is more about clean architecture and avoiding heuristics in a protocol parser. Since I am no real TLS implementor myself, I do not have any personal preference on whether or not to use an extra framing, and want to leave the discussion and in particular the decision to the author and those implementors who intend to implement this extension and those that are familiar with the requirement of small/constrained clients or low-bandwidth connections that expect a benefit from using this extension. -Martin From stefan@aaa-sec.com Tue Jun 16 09:01:20 2009 Return-Path: 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 3B92628C194 for ; Tue, 16 Jun 2009 09:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 SgVfzFl8cg4T for ; Tue, 16 Jun 2009 09:01:19 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 12D4728C188 for ; Tue, 16 Jun 2009 09:01:18 -0700 (PDT) Received: (qmail 54836 invoked from network); 16 Jun 2009 16:01:32 -0000 Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Jun 2009 16:01:32 -0000 Received: (qmail 41063 invoked from network); 16 Jun 2009 16:01:26 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 16 Jun 2009 16:01:26 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 16 Jun 2009 18:01:25 +0200 From: Stefan Santesson To: Stefan Santesson , Min Huang Message-ID: Thread-Topic: [TLS] First TLS cached information draft posted Thread-Index: AcnpmKU3A6jU6q9xQxOJfsECPeRUeQE+9phMAAHM5FY= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 16:01:20 -0000 Sorry, but I just have to disagree with myself. It's just messy and non-logical to include hashes of multiple objects in one and the same CachedOject structure. I propose the following text: The client 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. /Stefan On 09-06-16 5:09 PM, "Stefan Santesson" wrote: > This CachedObject stucture may contain any number of hashes. This might be > hashes using different algorithms over the same object or it may be hashes > of the same kind over different objects (e.g. multiple acceptble certs). It > is just an unordered list of hashes. From stefan@aaa-sec.com Tue Jun 16 09:09:05 2009 Return-Path: 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 CE75F3A6A9C for ; Tue, 16 Jun 2009 09:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 dfZ9OPOo1TTO for ; Tue, 16 Jun 2009 09:09:05 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 58E063A691F for ; Tue, 16 Jun 2009 09:08:35 -0700 (PDT) Received: (qmail 24706 invoked from network); 16 Jun 2009 15:40:27 -0000 Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Jun 2009 15:40:27 -0000 Received: (qmail 3634 invoked from network); 16 Jun 2009 15:40:21 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 16 Jun 2009 15:40:21 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 16 Jun 2009 17:40:15 +0200 From: Stefan Santesson To: Message-ID: Thread-Topic: [TLS] First TLS cached information draft posted Thread-Index: AcnumL4vV8tkVK9prkqUPb0pGSc3pg== In-Reply-To: <200906161529.n5GFT0iP007243@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: huangmin123@huaweisymantec.com, tls@ietf.org Subject: Re: [TLS] First TLS cached information draft posted 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 16:09:05 -0000 Martin, It may be that I misunderstand you because it is not clear to me what you would like to do instead. If you would spell out the ideal protocol flow exactly as you would prefer it, what would it be like? /Stefan On 09-06-16 5:29 PM, "Martin Rex" wrote: > Stefan Santesson wrote: >> >> This CachedObject stucture may contain any number of hashes. This might be >> hashes using different algorithms over the same object or it may be hashes >> of the same kind over different objects (e.g. multiple acceptble certs). It >> is just an unordered list of hashes. >> >> The server now takes the data it intended to send. And compute the hash over >> that data with as many algorithms it can out of the algorithms used by the >> client. If one of the received hashes matches one of the generated hashes, >> the match is accepted and the server will return one of the matching hashes >> as acceptance of the cache (data replacement). > > To me, this sounds more complex that I think it should be. > > I think the server should neither have to compute and neither have > to check the hash values for all hash algorithms for which the client > sent hashes. (which implies that the client has to send hash > values consistently for all items and all hash algorithms that > it wants to offer. > > The server should reply in the ServerHello extension for which items > and which hash algorithm (of those poposed by the client) it supports > substituting the real data with the replacement (the hash > value in the current proposal). > > The server should not have to compute and compare multiple hash > values over the real value when composing the handshake message > affected by the diet, and neither should the client have to > compare the substituted value to the hash values of more than > one hash algorithm (when the client proposed multiple values > for the same item with different hash algs. > > > -Martin From stefan@aaa-sec.com Tue Jun 16 10:13:37 2009 Return-Path: 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 59FB128C144 for ; Tue, 16 Jun 2009 10:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=-0.645, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 PDYWBikd7NiJ for ; Tue, 16 Jun 2009 10:13:34 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 6C3C628C182 for ; Tue, 16 Jun 2009 10:13:32 -0700 (PDT) Received: (qmail 88145 invoked from network); 16 Jun 2009 17:13:45 -0000 Received: from s34.loopia.se (HELO s60.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Jun 2009 17:13:45 -0000 Received: (qmail 57227 invoked from network); 16 Jun 2009 17:13:38 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 16 Jun 2009 17:13:38 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 16 Jun 2009 19:13:36 +0200 From: Stefan Santesson To: TLS wg , Simon Josefsson , Martin Rex Message-ID: Thread-Topic: Cached Info extension - Draft 01 Thread-Index: AcnupciksZ4dcEEcikS0nS3ipZ6kbQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3328024418_1676804" Subject: [TLS] Cached Info extension - Draft 01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:13:37 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3328024418_1676804 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I decided it was easier to explain my suggestions by incorporating it into = a new draft and submit it. Draft 01 is currently in staging at: http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-info-01.txt This indicates by no means that I think we have reached an agreement on thi= s issue, but it at least we have a version that represents a better starting point for change discussions. I did however include Simon=B9s suggested wording amendment in the beginning of section 4. /Stefan --B_3328024418_1676804 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cached Info extension - Draft 01 I decided it was easier to explain my suggestions by incorporating it into= a new draft and submit it.

Draft 01 is currently in staging at:
http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-info-= 01.txt

This indicates by no means that I think we have reached an agreement on thi= s issue, but it at least we have a version that represents a better starting= point for change discussions.

I did however include Simon’s suggested wording amendment in the begi= nning of section 4.

/Stefan --B_3328024418_1676804-- From ngm@google.com Mon Jun 22 12:14:06 2009 Return-Path: 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 20C803A6C40 for ; Mon, 22 Jun 2009 12:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 N3oXY2ZEjRAB for ; Mon, 22 Jun 2009 12:14:05 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id C79343A6DDF for ; Mon, 22 Jun 2009 12:13:41 -0700 (PDT) Received: from spaceape8.eur.corp.google.com (spaceape8.eur.corp.google.com [172.28.16.142]) by smtp-out.google.com with ESMTP id n5MJDuRZ031788 for ; Mon, 22 Jun 2009 12:13:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1245698037; bh=NwyG3vrs7GNM3ykF5dnwdtrdbYE=; h=DomainKey-Signature:MIME-Version:Date:Message-ID:Subject:From:To: Content-Type:Content-Transfer-Encoding:X-System-Of-Record; b=MS5zp FzDtzz/60NlkCTpPmVGycD5uF0hcrCaZlt5HADVebmT/irVJvmvcekD2d4bQ5mU6D8B ym4wbnKKNRUMVQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type: content-transfer-encoding:x-system-of-record; b=Zmj7XMgg8wJ20VlkNLFnwkCaXRNrmjGhMUf9wUfxl3XEnVzgPV1KO1A4z/4HMDsyH GD8FOvgGqC+lH8Ge8TdxA== Received: from gxk28 (gxk28.prod.google.com [10.202.11.28]) by spaceape8.eur.corp.google.com with ESMTP id n5MJDPOC009235 for ; Mon, 22 Jun 2009 12:13:54 -0700 Received: by gxk28 with SMTP id 28so6377950gxk.14 for ; Mon, 22 Jun 2009 12:13:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.74.7 with SMTP id w7mr5487050aga.33.1245697555688; Mon, 22 Jun 2009 12:05:55 -0700 (PDT) Date: Mon, 22 Jun 2009 12:05:54 -0700 Message-ID: <28425e380906221205k573972eblcff591d51634621d@mail.gmail.com> From: Nagendra Modadugu To: TLS wg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true Subject: [TLS] clarifications on TLS extension "Certificate Status Request" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 19:14:06 -0000 I am currently implementing the "Certificate Status Request" extension (RFC4366) for NSS. The primary use of this implementation will be OCSP verification of certificates presented by SSL websites. For the general Internet context, I am unable to find a case where a client should specify a non-empty responder_id_list. But in any case, say that the client does specify a responderID (to a general SSL webserver), what is the server supposed to do? The responderID is supposed to be either 1) the hash of the responder public key, or 2) a name (convention appears to be SubjectName of the responder). Unless convention for a responderID "name" is a AIA URL (and clients use a URL over a hash), the webserver will have to be pre-configured to determine appropriate end-points for each possible responder. What is the recommended way to specify responderIDs? Also, for the next revision of this RFC, it would useful to allow servers to return multiple OCSP responses, as EV certificates tend to be chained. nagendra From stefan@aaa-sec.com Wed Jun 24 03:44:13 2009 Return-Path: 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 1BF8128C1E5 for ; Wed, 24 Jun 2009 03:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 bKCrxAq1Aerv for ; Wed, 24 Jun 2009 03:44:09 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 4FAC328C4A0 for ; Wed, 24 Jun 2009 03:43:51 -0700 (PDT) Received: (qmail 2903 invoked from network); 24 Jun 2009 10:44:01 -0000 Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 24 Jun 2009 10:44:01 -0000 Received: (qmail 3623 invoked from network); 24 Jun 2009 10:43:57 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 24 Jun 2009 10:43:57 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 24 Jun 2009 12:43:53 +0200 From: Stefan Santesson To: Stefan Santesson , TLS wg , Simon Josefsson , Martin Rex Message-ID: Thread-Topic: [TLS] Cached Info extension - Draft 01 Thread-Index: AcnupciksZ4dcEEcikS0nS3ipZ6kbQGEuHyp In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3328692237_4139634" Subject: Re: [TLS] Cached Info extension - Draft 01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 10:44:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3328692237_4139634 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable It was not my intention to kill off this discussion with this new draft. I=B9m wandering whether the silence is a sign of agreement, vacation or just = a giving up that the author will ever listen to reasonable arguments... /Stefan On 09-06-16 7:13 PM, "Stefan Santesson" wrote: > I decided it was easier to explain my suggestions by incorporating it int= o a > new draft and submit it. >=20 > Draft 01 is currently in staging at: > http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-info-01.txt >=20 > This indicates by no means that I think we have reached an agreement on t= his > issue, but it at least we have a version that represents a better startin= g > point for change discussions. >=20 > I did however include Simon=B9s suggested wording amendment in the beginnin= g of > section 4. >=20 > /Stefan >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --B_3328692237_4139634 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [TLS] Cached Info extension - Draft 01 It was not my intention to kill off this discussion with this new draft.
I’m wandering whether the silence is a sign of agreement, vacation or= just a giving up that the author will ever listen to reasonable arguments..= .

/Stefan


On 09-06-16 7:13 PM, "Stefan Santesson" <stefan@aaa-sec.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>I decided it was easier to explain my suggestion= s by incorporating it into a new draft and submit it.

Draft 01 is currently in staging at:
http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-info-= 01.txt

This indicates by no means that I think we have reached an agreement on thi= s issue, but it at least we have a version that represents a better starting= point for change discussions.

I did however include Simon’s suggested wording amendment in the begi= nning of section 4.

/Stefan
___________= ____________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tls
--B_3328692237_4139634-- From simon@josefsson.org Wed Jun 24 05:25:22 2009 Return-Path: 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 067E13A6C30 for ; Wed, 24 Jun 2009 05:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 3T0U7uhJoWT5 for ; Wed, 24 Jun 2009 05:25:21 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 8AE983A6BFE for ; Wed, 24 Jun 2009 05:25:19 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-60.bredband.comhem.se [80.216.24.60]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5OCODGa014226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Jun 2009 14:24:15 +0200 From: Simon Josefsson To: Stefan Santesson References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090624:stefan@aaa-sec.com::mumTGVNY2nYMt6id:Ifb X-Hashcash: 1:22:090624:tls@ietf.org::C1d3cu1Ibq0BrFcG:6rBz X-Hashcash: 1:22:090624:martin.rex@sap.com::kDu8FbK0bbj6N5iq:fvLe Date: Wed, 24 Jun 2009 14:24:13 +0200 In-Reply-To: (Stefan Santesson's message of "Wed, 24 Jun 2009 12:43:53 +0200") Message-ID: <87ljnhn7ki.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: TLS wg , Martin Rex Subject: Re: [TLS] Cached Info extension - Draft 01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 12:25:22 -0000 Stefan Santesson writes: > It was not my intention to kill off this discussion with this new draft. > > Iım wandering whether the silence is a sign of agreement, vacation or just a > giving up that the author will ever listen to reasonable arguments... I still prefer Martin's proposal to add framing, but could live with your approach. A mild problem that I don't think is fully covered yet is the complexity in transition to new hashes -- clients will forever need to send SHA-1 hashes to the server, it seems, to ensure interoperability? Or should the document contain some text that explains that servers should pick the "preferred" hash it supports, and that clients should cache that choice for future use? Additional text would then be needed to explain that if clients try the new hash later on, and it doesn't work, it should revert back to SHA-1 in case the server software was changed to not support the other hash. This aspects doesn't feel completely baked yet to me. > /Stefan > > > On 09-06-16 7:13 PM, "Stefan Santesson" wrote: > >> I decided it was easier to explain my suggestions by incorporating it into a >> new draft and submit it. >> >> Draft 01 is currently in staging at: >> http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-info-01.txt >> >> This indicates by no means that I think we have reached an agreement on this >> issue, but it at least we have a version that represents a better starting >> point for change discussions. >> >> I did however include Simonıs suggested wording amendment in the beginning of >> section 4. >> >> /Stefan >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From Martin.Rex@sap.com Wed Jun 24 05:46:26 2009 Return-Path: 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 1C82128C4A3 for ; Wed, 24 Jun 2009 05:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 J+gDfL8vsmSL for ; Wed, 24 Jun 2009 05:46:25 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 077D128C4A0 for ; Wed, 24 Jun 2009 05:46:24 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n5OCfTRx021488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jun 2009 14:41:29 +0200 (MEST) From: Martin Rex Message-Id: <200906241241.n5OCfS8g011647@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Wed, 24 Jun 2009 14:41:28 +0200 (MEST) In-Reply-To: <87ljnhn7ki.fsf@mocca.josefsson.org> from "Simon Josefsson" at Jun 24, 9 02:24:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org, Martin.Rex@sap.com Subject: Re: [TLS] Cached Info extension - Draft 01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 12:46:26 -0000 Simon Josefsson wrote: > > Stefan Santesson writes: > > > It was not my intention to kill off this discussion with this new draft. > > > > Iım wandering whether the silence is a sign of agreement, vacation or just a > > giving up that the author will ever listen to reasonable arguments... > > I still prefer Martin's proposal to add framing, but could live with > your approach. > > A mild problem that I don't think is fully covered yet is the complexity > in transition to new hashes -- clients will forever need to send SHA-1 > hashes to the server, it seems, to ensure interoperability? Or should > the document contain some text that explains that servers should pick > the "preferred" hash it supports, and that clients should cache that > choice for future use? Additional text would then be needed to explain > that if clients try the new hash later on, and it doesn't work, it > should revert back to SHA-1 in case the server software was changed to > not support the other hash. This aspects doesn't feel completely baked > yet to me. How about extending the ClientHello and ServerHello extension with a pure negotiation of the supported Hash algorithms? So that in the first request, when the client does not have any cached data (and no hash values to propose), only the hash algorithm is "negotiated", plus the data elements for which the server supports caching in principle? This way, the client can learn which hash algorithm the server supports before filling his cache, and the client can also abstain from caching for servers that do not support the extension at all and abstain from caching particular handshake data, for which the server does not support caching. -Martin From root@core3.amsl.com Wed Jun 24 10:00:02 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 062CD3A6FAA; Wed, 24 Jun 2009 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090624170002.062CD3A6FAA@core3.amsl.com> Date: Wed, 24 Jun 2009 10:00:02 -0700 (PDT) Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-cached-info-01.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 17:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Cached Information Extension Author(s) : S. Santesson, Q. Dang Filename : draft-ietf-tls-cached-info-01.txt Pages : 6 Date : 2009-6-24 This document defines a Transport Layer Security (TLS) extension for cached information. This extension allows the TLS client to inform a server of cached information from previous TLS sessions, allowing the server to omit sending cached static information to the client during the TLS handshake protocol exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-cached-info-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-cached-info-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-6-24094718.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Jun 24 16:30:02 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0C1DD3A6D83; Wed, 24 Jun 2009 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090624233002.0C1DD3A6D83@core3.amsl.com> Date: Wed, 24 Jun 2009 16:30:02 -0700 (PDT) Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc4366-bis-05.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 23:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Extensions: Extension Definitions Author(s) : D. Eastlake 3rd Filename : draft-ietf-tls-rfc4366-bis-05.txt Pages : 28 Date : 2009-6-24 This document provides specifications for existing TLS extensions. It is a companion document for the TLS 1.2 specification [RFC5246]. The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-rfc4366-bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-6-24162103.I-D@ietf.org> --NextPart-- From Michael.Tuexen@lurchi.franken.de Mon Jun 29 07:49:30 2009 Return-Path: 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 57CD33A67B5 for ; Mon, 29 Jun 2009 07:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 P3yK+Vxn1+s2 for ; Mon, 29 Jun 2009 07:49:29 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 456AC3A6774 for ; Mon, 29 Jun 2009 07:49:29 -0700 (PDT) Received: from [IPv6:2002:508f:e509::224:36ff:feef:67d1] (unknown [IPv6:2002:508f:e509:0:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id 02BE41C0B3068 for ; Mon, 29 Jun 2009 16:49:45 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: tls@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 29 Jun 2009 16:49:44 +0200 X-Mailer: Apple Mail (2.935.3) Subject: [TLS] DTLS record layer processing 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 14:49:30 -0000 Dear all, when DTLS receives a packet is has to do input validation on the version number and the length given in the record header and the actual length of the UDP packet. When should this be done and what should be the action taken when the checks fail? There is an implementation out, which considers a version mismatch or a length given in the record layer which is larger than allowed by the protocol a fatal error. This might be OK for TLS, but I think is inacceptable for DTLS. An attacker only needs to guess the UDP port numbers and IP addresses and can craft a UDP packet with an illegal record length field and the DTLS connection is gone. Also http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-02.txt states In general, DTLS implementations SHOULD silently discard data with bad MACs. If a DTLS implementation chooses to generate an alert when it receives a message with an invalid MAC, it MUST generate a bad_record_mac alert with level fatal and terminate its connection state. If I understand things correctly, this means that as an attacker I need only to send a UDP packet with a wrong MAC to perform a DOS attack. Am I wrong? Any suggestions? Best regards Michael From ekr@networkresonance.com Tue Jun 30 09:24:56 2009 Return-Path: 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 3AD2A28C3CC for ; Tue, 30 Jun 2009 09:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.192 X-Spam-Level: X-Spam-Status: No, score=-0.192 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1] 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 5u1npEl+MHhF for ; Tue, 30 Jun 2009 09:24:54 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 50EB03A6A3E for ; Tue, 30 Jun 2009 09:24:45 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D51561C5ED3; Tue, 30 Jun 2009 09:24:43 -0700 (PDT) Date: Tue, 30 Jun 2009 09:24:43 -0700 From: Eric Rescorla To: Michael =?ISO-8859-1?Q?T=FCxen?= In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20090630162443.D51561C5ED3@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] DTLS record layer processing 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 16:24:56 -0000 At Mon, 29 Jun 2009 16:49:44 +0200, Michael T=FCxen wrote: >=20 > Dear all, >=20 > when DTLS receives a packet is has to do input validation on > the version number and the length given in the record header > and the actual length of the UDP packet. >=20 > When should this be done and what should be the action taken > when the checks fail? It should discard the datagram. > There is an implementation out, which considers a version > mismatch or a length given in the record layer which is > larger than allowed by the protocol a fatal error. > This might be OK for TLS, but I think is inacceptable for > DTLS. An attacker only needs to guess the UDP port numbers > and IP addresses and can craft a UDP packet with an illegal > record length field and the DTLS connection is gone. I agree, that that's not how implementations should behave. > Also > http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-02.txt > states >=20 > In general, DTLS implementations SHOULD silently discard data with > bad MACs. If a DTLS implementation chooses to generate an alert =20 > when > it receives a message with an invalid MAC, it MUST generate a > bad_record_mac alert with level fatal and terminate its connection > state. >=20 > If I understand things correctly, this means that as an attacker > I need only to send a UDP packet with a wrong MAC to perform > a DOS attack. > > Am I wrong? Any suggestions? I don't read the text that way. Rather, I think it says: If you receive a packet with a bad MAC, you must either: (a) Silently discard [Preferred] (b) Generate a bad_record_mac alert and terminate the connection. What you must not do is generate any other alert and continue the connection. This was designed to avoid attacks where the attacker repeatedly probed the victim implementation to see which error it generated. -Ekr From Michael.Tuexen@lurchi.franken.de Tue Jun 30 11:34:30 2009 Return-Path: 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 9904628C212 for ; Tue, 30 Jun 2009 11:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[AWL=-2.169, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] 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 PUI6rA1EKwRV for ; Tue, 30 Jun 2009 11:34:11 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 81B1E3A67FF for ; Tue, 30 Jun 2009 11:33:41 -0700 (PDT) Received: from [192.168.1.100] (p508FD1FD.dip.t-dialin.net [80.143.209.253]) by mail-n.franken.de (Postfix) with ESMTP id AEF611C0B4619; Tue, 30 Jun 2009 20:33:58 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Eric Rescorla In-Reply-To: <20090630162443.D51561C5ED3@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 30 Jun 2009 20:33:57 +0200 References: <20090630162443.D51561C5ED3@kilo.networkresonance.com> X-Mailer: Apple Mail (2.935.3) Cc: tls@ietf.org Subject: Re: [TLS] DTLS record layer processing 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 18:34:30 -0000 On Jun 30, 2009, at 6:24 PM, Eric Rescorla wrote: > At Mon, 29 Jun 2009 16:49:44 +0200, > Michael T=FCxen wrote: >> >> Dear all, >> >> when DTLS receives a packet is has to do input validation on >> the version number and the length given in the record header >> and the actual length of the UDP packet. >> >> When should this be done and what should be the action taken >> when the checks fail? > > It should discard the datagram. Silently, I assume. Should this be specified somewhere? http://www.ietf.org/rfc/rfc5246.txt says: record_overflow A TLSCiphertext record was received that had a length more than 2^14+2048 bytes, or a record decrypted to a TLSCompressed record with more than 2^14+1024 bytes. This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). Maybe people use this TLS based procedure also for DTLS (like =20 OpenSSL)... > > >> There is an implementation out, which considers a version >> mismatch or a length given in the record layer which is >> larger than allowed by the protocol a fatal error. >> This might be OK for TLS, but I think is inacceptable for >> DTLS. An attacker only needs to guess the UDP port numbers >> and IP addresses and can craft a UDP packet with an illegal >> record length field and the DTLS connection is gone. > > I agree, that that's not how implementations should behave. > > >> Also >> http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-02.txt >> states >> >> In general, DTLS implementations SHOULD silently discard data with >> bad MACs. If a DTLS implementation chooses to generate an alert >> when >> it receives a message with an invalid MAC, it MUST generate a >> bad_record_mac alert with level fatal and terminate its connection >> state. >> >> If I understand things correctly, this means that as an attacker >> I need only to send a UDP packet with a wrong MAC to perform >> a DOS attack. >> >> Am I wrong? Any suggestions? > > I don't read the text that way. Rather, I think it says: > > If you receive a packet with a bad MAC, you must either: > > (a) Silently discard [Preferred] > (b) Generate a bad_record_mac alert and terminate the connection. I agree, but my point is: If an implementation chooses (b), you can just send a malicious packet and the connection is gone. Or am I missing something? > > What you must not do is generate any other alert and continue > the connection. Understood. > > This was designed to avoid attacks where the attacker repeatedly > probed the victim implementation to see which error it generated. Understood, but I think (b) is bad in any case for DTLS. So why not get rid of it and just require that implementation MUST use (a), or at least SHOULD. At least for DTLS/UDP. For DTLS/SCTP it is OK to send an alert since an attacker can not insert packets because they are protected also with SCTP-AUTH. > > -Ekr > From stefan@aaa-sec.com Tue Jun 30 18:12:16 2009 Return-Path: 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 1235D3A65A6 for ; Tue, 30 Jun 2009 18:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.173 X-Spam-Level: X-Spam-Status: No, score=-1.173 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_QP_LONG_LINE=1.396] 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 wqV3Jsmemd9b for ; Tue, 30 Jun 2009 18:12:15 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id B88723A67ED for ; Tue, 30 Jun 2009 18:12:13 -0700 (PDT) Received: (qmail 5991 invoked from network); 1 Jul 2009 01:12:41 -0000 Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 1 Jul 2009 01:12:41 -0000 Received: (qmail 14937 invoked from network); 1 Jul 2009 01:12:31 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 1 Jul 2009 01:12:31 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 01 Jul 2009 03:12:30 +0200 From: Stefan Santesson To: , Simon Josefsson Message-ID: Thread-Topic: [TLS] Cached Info extension - Draft 01 Thread-Index: Acn56QE54G0UsQ8f7kiQ72gV5jTKjQ== In-Reply-To: <200906241241.n5OCfS8g011647@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Cached Info extension - Draft 01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 01:12:16 -0000 I might be missing something, but I'm not sure I get the problem. One difficulty I have is that I don't see, and never have seen, the reason to provide different levels of hash algorithms for a usage that does not require a strong hash. But even if the client decides to do this, the server can pick any of the hashes as the return value. That hash is long and random enough to work as = a perfectly unambiguous identifier of a successfully replaced cached object, and is long and random enough to reduce the chance of accidental collisions of any kind to totally negligible probabilities. Maybe we should sit down in Stockholm and come up with a solution that hopefully makes everyone happy. /Stefan On 09-06-24 2:41 PM, "Martin Rex" wrote: > Simon Josefsson wrote: >>=20 >> Stefan Santesson writes: >>=20 >>> It was not my intention to kill off this discussion with this new draft= . >>>=20 >>> I=B9m wandering whether the silence is a sign of agreement, vacation or j= ust a >>> giving up that the author will ever listen to reasonable arguments... >>=20 >> I still prefer Martin's proposal to add framing, but could live with >> your approach. >>=20 >> A mild problem that I don't think is fully covered yet is the complexity >> in transition to new hashes -- clients will forever need to send SHA-1 >> hashes to the server, it seems, to ensure interoperability? Or should >> the document contain some text that explains that servers should pick >> the "preferred" hash it supports, and that clients should cache that >> choice for future use? Additional text would then be needed to explain >> that if clients try the new hash later on, and it doesn't work, it >> should revert back to SHA-1 in case the server software was changed to >> not support the other hash. This aspects doesn't feel completely baked >> yet to me. >=20 >=20 > How about extending the ClientHello and ServerHello extension > with a pure negotiation of the supported Hash algorithms? >=20 > So that in the first request, when the client does not have any cached > data (and no hash values to propose), only the hash algorithm is > "negotiated", plus the data elements for which the server supports > caching in principle? >=20 > This way, the client can learn which hash algorithm the server > supports before filling his cache, and the client can also abstain > from caching for servers that do not support the extension at all > and abstain from caching particular handshake data, for which the > server does not support caching. >=20 >=20 > -Martin