From mccorquodaleanna@amcmanagement.co.uk Mon Dec 1 17:50:09 2008 Return-Path: X-Original-To: ietfarch-tls-archive@core3.amsl.com Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF3C3A6ACF for ; Mon, 1 Dec 2008 17:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.352 X-Spam-Level: X-Spam-Status: No, score=-30.352 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, 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 a-ZAgZ1mFJOr for ; Mon, 1 Dec 2008 17:50:09 -0800 (PST) Received: from 61-90-219-170.static.asianet.co.th (61-90-219-170.static.asianet.co.th [61.90.219.170]) by core3.amsl.com (Postfix) with SMTP id 1B08E3A6AB9 for ; Mon, 1 Dec 2008 17:50:05 -0800 (PST) To: Subject: cloder to ideal steak From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081202015007.1B08E3A6AB9@core3.amsl.com> Date: Mon, 1 Dec 2008 17:50:05 -0800 (PST)

Having trouble viewing this email?
Click here to view as a webpage.

From tls-bounces@ietf.org Tue Dec 2 11:27:32 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5814228C18B; Tue, 2 Dec 2008 11:27:32 -0800 (PST) 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 8D59A28C18B for ; Tue, 2 Dec 2008 11:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ahvSrd+S36Mk for ; Tue, 2 Dec 2008 11:27:30 -0800 (PST) Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by core3.amsl.com (Postfix) with ESMTP id 939BE28B797 for ; Tue, 2 Dec 2008 11:27:30 -0800 (PST) Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 2 Dec 2008 19:27:22 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.9]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Tue, 2 Dec 2008 19:27:22 +0000 From: Stefan Santesson To: "tls@ietf.org" Date: Tue, 2 Dec 2008 19:27:23 +0000 Thread-Topic: TLS Fast-Track resurrected? Thread-Index: AclP3jmt4IGDvm+8SQ2SsPkGaCbG/gE1Dzaw Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> References: <0016364584386e8572045c8e8024@google.com> from "ernuzwang@gmail.com" at Nov 26, 8 02:36:56 am <200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp> In-Reply-To: <200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org At the last IETF I brought up the question whether we should bring the old TLS Fast-Track work back to life. The general opinion was positive. In short, my proposal is to generate a new draft inspired by the old TLS Fast Track draft (http://tools.ietf.org/html/draft-shacham-tls-fast-track-00) The new proposal would change the old proposal in the following way: * Only use extensions. Not defining new Client and Server Hello messages * Keep general design of the fast-track extension but add hash algorithm agility. * Reduce determining parameters to be hashed. I'm open to suggestions on how to, if at all, reduce the old determining parameters from Fast Track section 4.1, but I would suggest to just hash the server certificate and then do a normal TLS session setup except from not sending over the TLS server certificate if the client has correctly identified the server certificate in the client hello extension. We may lose some degree of optimization, but would gain in simplicity. Stefan Santesson Senior Program Manager Windows Security, Standards _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From mmcr@ahdubai.com Tue Dec 2 23:15:10 2008 Return-Path: X-Original-To: ietfarch-tls-archive@core3.amsl.com Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20F333A69B6 for ; Tue, 2 Dec 2008 23:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.275 X-Spam-Level: X-Spam-Status: No, score=-22.275 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, 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 5yV02yZo3iAa for ; Tue, 2 Dec 2008 23:15:09 -0800 (PST) Received: from advancedmedicaltransport.com (unknown [200.61.161.177]) by core3.amsl.com (Postfix) with SMTP id 5349B3A6A55 for ; Tue, 2 Dec 2008 23:15:07 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081203071508.5349B3A6A55@core3.amsl.com> Date: Tue, 2 Dec 2008 23:15:07 -0800 (PST)

From tls-bounces@ietf.org Wed Dec 3 02:15:25 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C17B28C0F7; Wed, 3 Dec 2008 02:15:25 -0800 (PST) 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 9532928C0F7 for ; Wed, 3 Dec 2008 02:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, 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 REHDJYzzV9f5 for ; Wed, 3 Dec 2008 02:15:23 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6E1D228C0F1 for ; Wed, 3 Dec 2008 02:15:23 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mB3AEruw020291; Wed, 3 Dec 2008 12:15:16 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 12:15:12 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 12:15:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 12:15:13 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720276B0CB@vaebe104.NOE.Nokia.com> In-Reply-To: <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS Fast-Track resurrected? Thread-Index: AclP3jmt4IGDvm+8SQ2SsPkGaCbG/gE1DzawAB6mFLA= References: <0016364584386e8572045c8e8024@google.com> from"ernuzwang@gmail.com" at Nov 26, 8 02:36:56 am<200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> From: To: , X-OriginalArrivalTime: 03 Dec 2008 10:15:12.0030 (UTC) FILETIME=[06F54BE0:01C95530] X-Nokia-AV: Clean Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org If we do this, I'd suggest also including the "certificate_authorities" list from CertificateRequest. If the trust anchor list is large (as it often is in e.g. typical Windows setups), that's easily over 3 KB (similar size, or even larger, than the server certificate chain). And it's often sent even if the client won't actually use TLS client authentication. A data point: I took a dump of TLS-protected handshake done by an unnamed Microsoft product (no session resumption, no client authentication). The TLS handshake messages were 7391 bytes. With a simple "send SHA-256 hash of server certificate and certificate_authorities list in ClientHello extension" design, that would have been about 415 bytes, saving almost 7 KB (over 90%). (If this was just e.g. 25%, it IMHO wouldn't be worth doing -- it wouldn't be a good engineering tradeoff between added complexity and saved bytes. But if we save over 90%, that sounds much better...) Best regards, Pasi > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On > Behalf Of ext Stefan Santesson > Sent: 02 December, 2008 21:27 > To: tls@ietf.org > Subject: [TLS] TLS Fast-Track resurrected? > > At the last IETF I brought up the question whether we should > bring the old TLS Fast-Track work back to life. > The general opinion was positive. > > In short, my proposal is to generate a new draft inspired by > the old TLS Fast Track draft > (http://tools.ietf.org/html/draft-shacham-tls-fast-track-00) > The new proposal would change the old proposal in the following way: > > * Only use extensions. Not defining new Client and Server > Hello messages > * Keep general design of the fast-track extension but add > hash algorithm agility. > * Reduce determining parameters to be hashed. > > I'm open to suggestions on how to, if at all, reduce the old > determining parameters from Fast Track section 4.1, but I > would suggest to just hash the server certificate and then do > a normal TLS session setup except from not sending over the > TLS server certificate if the client has correctly identified > the server certificate in the client hello extension. > > We may lose some degree of optimization, but would gain in simplicity. > > > > Stefan Santesson > Senior Program Manager > Windows Security, Standards > > _______________________________________________ > 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 tls-bounces@ietf.org Wed Dec 3 07:28:17 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3CB33A6AA9; Wed, 3 Dec 2008 07:28:17 -0800 (PST) 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 DC6183A6AA9 for ; Wed, 3 Dec 2008 07:28:16 -0800 (PST) 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 bUAcZ94JgMQO for ; Wed, 3 Dec 2008 07:28:16 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id BC0233A68C3 for ; Wed, 3 Dec 2008 07:28:15 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id mB3FSAGk016231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2008 16:28:10 +0100 (MET) From: Martin Rex Message-Id: <200812031528.mB3FS9xL018461@fs4113.wdf.sap.corp> To: stefans@microsoft.com (Stefan Santesson) Date: Wed, 3 Dec 2008 16:28:09 +0100 (MET) In-Reply-To: <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> from "Stefan Santesson" at Dec 2, 8 07:27:23 pm MIME-Version: 1.0 X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Stefan Santesson wrote: > > At the last IETF I brought up the question whether we should bring > the old TLS Fast-Track work back to life. > The general opinion was positive. > > In short, my proposal is to generate a new draft inspired by the old TLS > Fast Track draft (http://tools.ietf.org/html/draft-shacham-tls-fast-track-00) > The new proposal would change the old proposal in the following way: > > * Only use extensions. Not defining new Client and Server Hello messages > * Keep general design of the fast-track extension but add hash algorithm > agility. > * Reduce determining parameters to be hashed. > > I'm open to suggestions on how to, if at all, reduce the old determining > parameters from Fast Track section 4.1, but I would suggest to just hash > the server certificate and then do a normal TLS session setup except > from not sending over the TLS server certificate if the client has > correctly identified the server certificate in the client hello extension. > > We may lose some degree of optimization, but would gain in simplicity. I briefly read through the document and to me it appears to be a complex and extremly ugly mutilation and contortion of the TLS protocol. If at all, I would appreciate an approach that is orthogonal to other TLS extensions and with minimal impact on the regular TLS handshake. How about an approach with one "simple" TLS (client) hello extension where the client can provide a _list_ of parameters it has cached along with a hash over the value, and where the server can decide for each entry/hash in the list whether to send the information or whether to send a short replacement tag that indicates to the client that he should use his cached information. Two possibilities: a list of integer-tag plus hash-value or a list of bitfield plus hash-value the integer tags (or the bits of the bitfield) should be standardized/ registered so that the cached information is extensible, can also be used to signal cached values from other TLS extensions and the server can ignore cache hints that it doesn't understand. If a bitfield is used, it would be possible to create a single hash over a concatenation of several independent cached values, however the number space is much smaller and would have to be managed more carefully. Alternatively, one could assign integer-tags to indicate that the hash is over a concatenation of a specific set of cached values. The original document claims that the number of round-trips could be reduced through the the use of the modified FastTrack-Handshake -- but I don't think this is generally true. In the normal case, the client that opens the communication channel and starts the TLS handshake will also be the one who sends the first application data. Technically, the client can piggy-back that first application data onto the Clients Finished handshake message as long as the client trusts in the encryption of the established TLS communication channel (to me that is similar to the GSS-API v2 PROT_READY approach). I don't see a significant technical reason why the client should have to wait for the servers Finished handshake message -- other than the client might start to consume a significant network bandwidth without knowing whether the TLS handshake was actually completed successfully. Personally, I wouldn't mind if the client only did start sending application data before receiving the servers ChangeCipherSpec&Finished message in case that the server has agreed to perform an optimized fast track handshake (by omitting those parts of information from the regular TLS handshake where the client-signalled hash matches the information that the server would normally send in the handshake. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 3 14:30:36 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A886428C18F; Wed, 3 Dec 2008 14:30:36 -0800 (PST) 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 2539D3A69A9 for ; Wed, 3 Dec 2008 14:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVGK3hD8z-x3 for ; Wed, 3 Dec 2008 14:30:31 -0800 (PST) Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 272473A6358 for ; Wed, 3 Dec 2008 14:30:29 -0800 (PST) Received: from localhost.localdomain (unknown [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 654BE1809E for ; Wed, 3 Dec 2008 17:30:24 -0500 (EST) Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id F188018095 for ; Wed, 3 Dec 2008 17:30:23 -0500 (EST) Message-ID: <4937088E.3010001@pobox.com> Date: Wed, 03 Dec 2008 14:30:38 -0800 From: Mike User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "tls@ietf.org" References: <0016364584386e8572045c8e8024@google.com> from "ernuzwang@gmail.com" at Nov 26, 8 02:36:56 am <200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> In-Reply-To: <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> X-Pobox-Relay-ID: FA3DF3FE-C189-11DD-895A-F83E113D384A-38729857!a-sasl-quonix.pobox.com Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org This is an interesting idea, but quite complex for what it appears to want to do. Instead of trying to come up with a collection of fast-track parameters and hashing them all together, keeping them separate would be simpler and more flexible. For example, one of the major goals is for the server to not send its Certificate message. To accommodate this optimization, there could be a cached_server_certificate extension which would contain a server-defined value that represents its certificate (most likely a hash). The first connection a client makes would contain an empty cached_server_certificate extension. If the server knows about the extension, it replies with the same extension, but which has been filled with a value that it associates with its certificate chain. The value can be a hash of the end entity certificate or of the whole chain, or even just a sequential number it increases each time its certificate is replaced. Leaving the format of the value unspecified provides hash agility since a server can use any hash it wants. For this initial handshake, the server must also send its Certificate message, since the client does not yet have a copy of it. When the client reconnects, it provides the server's value from a previous handshake in its cached_server_certificate extension. If the server can match the value to one of its certificate chains, then it replies with the same value in its extension and does not send the Certificate message during the handshake. If the value is unrecognized, the server acts as if the client's extension was empty. I didn't think too much about the other parameters that might also benefit from fast-tracking, but they can probably be similarly defined. But adding just this simple extension will probably save the majority of the bandwidth (since few connections use client authentication). Mike Stefan Santesson wrote: > At the last IETF I brought up the question whether we should bring the old TLS Fast-Track work back to life. > The general opinion was positive. > > In short, my proposal is to generate a new draft inspired by the old TLS Fast Track draft (http://tools.ietf.org/html/draft-shacham-tls-fast-track-00) > The new proposal would change the old proposal in the following way: > > * Only use extensions. Not defining new Client and Server Hello messages > * Keep general design of the fast-track extension but add hash algorithm agility. > * Reduce determining parameters to be hashed. > > I'm open to suggestions on how to, if at all, reduce the old determining parameters from Fast Track section 4.1, but I would suggest to just hash the server certificate and then do a normal TLS session setup except from not sending over the TLS server certificate if the client has correctly identified the server certificate in the client hello extension. > > We may lose some degree of optimization, but would gain in simplicity. > > Stefan Santesson > Senior Program Manager > Windows Security, Standards _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 3 15:01:30 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ED433A6B9A; Wed, 3 Dec 2008 15:01:30 -0800 (PST) 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 A74DE3A6B9A for ; Wed, 3 Dec 2008 15:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.843 X-Spam-Level: X-Spam-Status: No, score=-5.843 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 w6E5SiWgRSJ8 for ; Wed, 3 Dec 2008 15:01:28 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id DC4793A6A6F for ; Wed, 3 Dec 2008 15:01:27 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mB3N1Nne019091 for ; Wed, 3 Dec 2008 23:01:23 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mB3N1N4Q004548 for ; Wed, 3 Dec 2008 16:01:23 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mB3Mr2Hb025322; Wed, 3 Dec 2008 16:53:02 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mB3Mr2no025321; Wed, 3 Dec 2008 16:53:02 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 3 Dec 2008 16:53:02 -0600 From: Nicolas Williams To: Stefan Santesson Message-ID: <20081203225301.GS22970@Sun.COM> References: <0016364584386e8572045c8e8024@google.com> <200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org draft-shacham-tls-fast-track-00 claims stateful session resumption as a motivator for that work. But RFC4507 fixes that problem. Are there other motivations for TLS Fast-Track given RFC4507? Let's put it another way. If a client and server support both, RFC4507 and Fast-Track, then: a) a client that chooses RFC4507 will not have an opportunity to use Fast-Track until the session ticket expires, b) RFC4507 resumption should be lighter-weight[*] than Fast-Track, so why would a client prefer to use Fast-Track instead of RFC4507? [*] Servers will typically have to perform a symmetric decryption operation for fast stateless session resumption (RFC4507); clients and servers also derive new session keys, otherwise that's it. Whereas Fast-Track always has a ClientKeyExchange, so there's always some public key operation in Fast-Track unless PSK is being used. As I see it RFC4507 should terminate all interest in Fast-Track. No? Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 3 15:31:03 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB803A68B9; Wed, 3 Dec 2008 15:31:03 -0800 (PST) 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 3198C3A68B9 for ; Wed, 3 Dec 2008 15:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 DmKVogWFxFsG for ; Wed, 3 Dec 2008 15:31:00 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 488A53A677D for ; Wed, 3 Dec 2008 15:31:00 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 54C8629C002; Thu, 4 Dec 2008 01:30:55 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id DA32A29C001; Thu, 4 Dec 2008 01:30:17 +0200 (IST) Received: from [172.31.21.205] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB3NUHfE021202; Thu, 4 Dec 2008 01:30:17 +0200 (IST) Message-Id: <7264CE19-EFBD-4D1F-82CD-2DEA09C9D7AA@checkpoint.com> From: Yoav Nir To: Nicolas Williams In-Reply-To: <20081203225301.GS22970@Sun.COM> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 4 Dec 2008 01:30:16 +0200 References: <0016364584386e8572045c8e8024@google.com> <200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> <20081203225301.GS22970@Sun.COM> X-Mailer: Apple Mail (2.929.2) Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Not really. Fast-Track is for establishing TLS when the old session ticket has already expired (maybe it's your first connection for the day). It makes the first connection (the one that can't benefit from session resumption, stateless or otherwise) take less bytes. That said, I'm not convinced it's all that useful without lots of assumptions about low bandwidth and charge-by-bytes. Most of us can afford to send a certificate chain every few hours. On Dec 4, 2008, at 12:53 AM, Nicolas Williams wrote: > draft-shacham-tls-fast-track-00 claims stateful session resumption > as a > motivator for that work. But RFC4507 fixes that problem. > > Are there other motivations for TLS Fast-Track given RFC4507? > > Let's put it another way. If a client and server support both, > RFC4507 > and Fast-Track, then: a) a client that chooses RFC4507 will not have > an > opportunity to use Fast-Track until the session ticket expires, b) > RFC4507 resumption should be lighter-weight[*] than Fast-Track, so why > would a client prefer to use Fast-Track instead of RFC4507? > > [*] Servers will typically have to perform a symmetric decryption > operation for fast stateless session resumption (RFC4507); clients > and servers also derive new session keys, otherwise that's it. > > Whereas Fast-Track always has a ClientKeyExchange, so there's > always > some public key operation in Fast-Track unless PSK is being used. > > As I see it RFC4507 should terminate all interest in Fast-Track. No? > > Nico _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 3 15:57:06 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17E23A6BDF; Wed, 3 Dec 2008 15:57:06 -0800 (PST) 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 6AE213A6BDF for ; Wed, 3 Dec 2008 15:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 LBL+Zla-tB2m for ; Wed, 3 Dec 2008 15:57:04 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by core3.amsl.com (Postfix) with ESMTP id 7B0FD3A67E2 for ; Wed, 3 Dec 2008 15:57:04 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-3.sun.com (8.13.8+Sun/8.12.9) with ESMTP id mB3NusZF011925 for ; Wed, 3 Dec 2008 23:56:56 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mB3NurkS022356 for ; Wed, 3 Dec 2008 16:56:53 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mB3Nf5ec025353; Wed, 3 Dec 2008 17:41:05 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mB3Nf5b5025352; Wed, 3 Dec 2008 17:41:05 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 3 Dec 2008 17:41:05 -0600 From: Nicolas Williams To: Yoav Nir Message-ID: <20081203234104.GU22970@Sun.COM> References: <0016364584386e8572045c8e8024@google.com> <200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> <20081203225301.GS22970@Sun.COM> <7264CE19-EFBD-4D1F-82CD-2DEA09C9D7AA@checkpoint.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <7264CE19-EFBD-4D1F-82CD-2DEA09C9D7AA@checkpoint.com> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org On Thu, Dec 04, 2008 at 01:30:16AM +0200, Yoav Nir wrote: > Not really. Fast-Track is for establishing TLS when the old session > ticket has already expired (maybe it's your first connection for the > day). It makes the first connection (the one that can't benefit from > session resumption, stateless or otherwise) take less bytes. I got that, but if you're doing session resumption w/o server-side state then the cost of one regular TLS handshake will be amortized over many resumptions, so what's the point of Fast-Track? > That said, I'm not convinced it's all that useful without lots of > assumptions about low bandwidth and charge-by-bytes. Most of us can > afford to send a certificate chain every few hours. Exactly! Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 3 15:59:48 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E340F28C1BD; Wed, 3 Dec 2008 15:59:48 -0800 (PST) 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 E99513A6BDF for ; Wed, 3 Dec 2008 15:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 MAbZ-deqdT4c for ; Wed, 3 Dec 2008 15:59:47 -0800 (PST) Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 370BD3A67E2 for ; Wed, 3 Dec 2008 15:59:46 -0800 (PST) Received: from localhost.localdomain (unknown [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id CA7DC180C2 for ; Wed, 3 Dec 2008 18:59:41 -0500 (EST) Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 75CD6180C1 for ; Wed, 3 Dec 2008 18:59:41 -0500 (EST) Message-ID: <49371D7B.5080002@pobox.com> Date: Wed, 03 Dec 2008 15:59:55 -0800 From: Mike User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "tls@ietf.org" References: <0016364584386e8572045c8e8024@google.com> <200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> <20081203225301.GS22970@Sun.COM> <7264CE19-EFBD-4D1F-82CD-2DEA09C9D7AA@checkpoint.com> In-Reply-To: <7264CE19-EFBD-4D1F-82CD-2DEA09C9D7AA@checkpoint.com> X-Pobox-Relay-ID: 73827508-C196-11DD-89D8-F83E113D384A-38729857!a-sasl-quonix.pobox.com Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org With the economy in a tailspin and people coming to the realization that they can't afford to live beyond their means, we may actually see some people cancel their DSL/Cable Internet and return to (gasp!) 56k modems. They will want server-side session caches and fast-track cert chain caching to minimize delays. Also looking at it from the server's perspective, if fast-track cert chain caching saves a few kB of bandwidth per client per day, you need to multiply that by the number of clients to see the true benefit. Mike Yoav Nir wrote: > I'm not convinced it's all that useful without lots of > assumptions about low bandwidth and charge-by-bytes. Most of us can > afford to send a certificate chain every few hours. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From modvarkon@alwil.cz Wed Dec 3 16:11:04 2008 Return-Path: X-Original-To: ietfarch-tls-archive@core3.amsl.com Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEEA228C146 for ; Wed, 3 Dec 2008 16:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.713 X-Spam-Level: X-Spam-Status: No, score=-10.713 tagged_above=-999 required=5 tests=[BAYES_95=3, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 cLFP-5CN0sGa for ; Wed, 3 Dec 2008 16:11:04 -0800 (PST) Received: from res-adsl005-A.bas501.cwt.esat.net (res-adsl005-A.bas501.cwt.esat.net [193.203.156.5]) by core3.amsl.com (Postfix) with SMTP id 12E423A68CE for ; Wed, 3 Dec 2008 16:11:01 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081204001103.12E423A68CE@core3.amsl.com> Date: Wed, 3 Dec 2008 16:11:01 -0800 (PST)

From tls-bounces@ietf.org Wed Dec 3 16:30:24 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39903A6BE4; Wed, 3 Dec 2008 16:30:24 -0800 (PST) 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 010653A6BDF for ; Wed, 3 Dec 2008 16:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 k6TMGHV7Wg2p for ; Wed, 3 Dec 2008 16:30:22 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 473E73A677D for ; Wed, 3 Dec 2008 16:30:22 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mB40UIwa024230 for ; Thu, 4 Dec 2008 00:30:18 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mB40UHc0060011 for ; Wed, 3 Dec 2008 17:30:18 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mB40LvvO025425; Wed, 3 Dec 2008 18:21:57 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mB40LpAO025424; Wed, 3 Dec 2008 18:21:51 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 3 Dec 2008 18:21:51 -0600 From: Nicolas Williams To: Mike Message-ID: <20081204002151.GZ22970@Sun.COM> References: <0016364584386e8572045c8e8024@google.com> <200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> <20081203225301.GS22970@Sun.COM> <7264CE19-EFBD-4D1F-82CD-2DEA09C9D7AA@checkpoint.com> <49371D7B.5080002@pobox.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <49371D7B.5080002@pobox.com> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org On Wed, Dec 03, 2008 at 03:59:55PM -0800, Mike wrote: > With the economy in a tailspin and people coming to the realization > that they can't afford to live beyond their means, we may actually see > some people cancel their DSL/Cable Internet and return to (gasp!) 56k > modems. They will want server-side session caches and fast-track cert > chain caching to minimize delays. Economic crises don't work that way. The real price of broadband is not likely to go up by so much that we'll end up using 56k, nor is the price of 56k lower now, and in any case, if you do session resumption w/o server-side state then you're amortizing one full handshake over many resumptions, so Fast-Track is pointless. > Also looking at it from the server's perspective, if fast-track cert > chain caching saves a few kB of bandwidth per client per day, you need > to multiply that by the number of clients to see the true benefit. That makes more sense. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Dec 3 17:21:39 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6EB3A681F; Wed, 3 Dec 2008 17:21:39 -0800 (PST) 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 15C043A681F for ; Wed, 3 Dec 2008 17:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmAmMIeUcxPk for ; Wed, 3 Dec 2008 17:21:37 -0800 (PST) Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by core3.amsl.com (Postfix) with ESMTP id 4FDC23A67EF for ; Wed, 3 Dec 2008 17:21:35 -0800 (PST) Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id B62EA844B4 for ; Wed, 3 Dec 2008 20:21:30 -0500 (EST) Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 5CA49844B3 for ; Wed, 3 Dec 2008 20:21:30 -0500 (EST) Message-ID: <493730A7.6000006@pobox.com> Date: Wed, 03 Dec 2008 17:21:43 -0800 From: Mike User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "tls@ietf.org" References: <0016364584386e8572045c8e8024@google.com> <200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> <20081203225301.GS22970@Sun.COM> <7264CE19-EFBD-4D1F-82CD-2DEA09C9D7AA@checkpoint.com> <49371D7B.5080002@pobox.com> <20081204002151.GZ22970@Sun.COM> In-Reply-To: <20081204002151.GZ22970@Sun.COM> X-Pobox-Relay-ID: E173C2C8-C1A1-11DD-8B34-5720C92D7133-38729857!a-sasl-fastnet.pobox.com Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org >> With the economy in a tailspin and people coming to the realization >> that they can't afford to live beyond their means, we may actually see >> some people cancel their DSL/Cable Internet and return to (gasp!) 56k >> modems. They will want server-side session caches and fast-track cert >> chain caching to minimize delays. > > Economic crises don't work that way. The real price of broadband is not > likely to go up by so much that we'll end up using 56k, nor is the price > of 56k lower now, and in any case, if you do session resumption w/o > server-side state then you're amortizing one full handshake over many > resumptions, so Fast-Track is pointless. It's not that I think broadband prices will go up, but that many people who currently pay for it will realize that they can't really afford it. It's been a long time since I priced dial-up, but a quick google search indicates you can save 50% or more over broadband by using dial-up. A lot of people are going to have to make the difficult choice to go back to a modem. The reason for fast-track is to make that one full handshake faster, by eliminating the transfer of the server's certificate chain (at least). This is also why a modem user would not enable client-side caching; it requires an extra payload to be transferred on every resumption. Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From oanamomof3@amacita.com Wed Dec 3 17:39:23 2008 Return-Path: X-Original-To: ietfarch-tls-archive@core3.amsl.com Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF4D3A6814 for ; Wed, 3 Dec 2008 17:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.085 X-Spam-Level: X-Spam-Status: No, score=-12.085 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 qCrqRIWUApfs for ; Wed, 3 Dec 2008 17:39:22 -0800 (PST) Received: from d23-214.rb.gh.centurytel.net (d23-214.rb.gh.centurytel.net [69.29.214.214]) by core3.amsl.com (Postfix) with SMTP id E762E3A65A5 for ; Wed, 3 Dec 2008 17:39:21 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081204013921.E762E3A65A5@core3.amsl.com> Date: Wed, 3 Dec 2008 17:39:21 -0800 (PST)

From tls-bounces@ietf.org Thu Dec 4 05:06:27 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFE83A6A57; Thu, 4 Dec 2008 05:06:27 -0800 (PST) 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 A788E3A6A6E for ; Thu, 4 Dec 2008 05:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, 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 hn9aKHUAk7pl for ; Thu, 4 Dec 2008 05:06:26 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A28F03A6A46 for ; Thu, 4 Dec 2008 05:06:25 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mB4D5wnG026876; Thu, 4 Dec 2008 15:06:18 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Dec 2008 15:05:57 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Dec 2008 15:05:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Dec 2008 15:05:53 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720276BD90@vaebe104.NOE.Nokia.com> In-Reply-To: <20081203225301.GS22970@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS Fast-Track resurrected? Thread-Index: AclVmxT70NTpHPpCSOq3ZMTm9DUjKQAc7SWA References: <0016364584386e8572045c8e8024@google.com><200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp><9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> <20081203225301.GS22970@Sun.COM> From: To: X-OriginalArrivalTime: 04 Dec 2008 13:05:56.0324 (UTC) FILETIME=[0B724240:01C95611] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Nicolas Williams worte: > As I see it RFC4507 should terminate all interest in Fast-Track. No? They would operate on quite different time scales. TLS session resumption (with or without server-side state) requires storing confidential information (the master secret), and a TLS client probably won't use persistent storage for it. Also, RFC 5246 suggests an upper limit of 24 hours for session cache entries. The server certificate (and certificate_authorities list), on the other hand, are not secret, and could be stored (on disk) for months or years. But yes, you do have a point in that an optimization that gets used only once a day (or once every TLS client restart) isn't that great optimization from the client's point of view (server's point of view may be different). Best regards, Pasi _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Dec 4 06:07:59 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E713A6A86; Thu, 4 Dec 2008 06:07:59 -0800 (PST) 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 E06B33A6AA2 for ; Thu, 4 Dec 2008 06:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 rzsgTg7r-Auf for ; Thu, 4 Dec 2008 06:07:57 -0800 (PST) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 146253A68DF for ; Thu, 4 Dec 2008 06:07:52 -0800 (PST) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id mB4F7MUO962694; Thu, 4 Dec 2008 15:07:22 GMT Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Thu, 4 Dec 2008 15:04:53 +0100 (CET) Message-ID: <51651.88.164.98.77.1228399493.squirrel@www.isima.fr> In-Reply-To: <1696498986EFEC4D9153717DA325CB720276BD90@vaebe104.NOE.Nokia.com> References: <0016364584386e8572045c8e8024@google.com><200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp><9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com><20081203225301.GS22970@Sun.COM> <1696498986EFEC4D9153717DA325CB720276BD90@vaebe104.NOE.Nokia.com> Date: Thu, 4 Dec 2008 15:04:53 +0100 (CET) From: "Mohamad Badra" To: Pasi.Eronen@nokia.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 04 Dec 2008 15:07:37 +0000 (WET) Cc: =?utf-8?Q?=C2?= Subject: [TLS] =?utf-8?b?IFJlOsKgwqBUTFPCoEZhc3QtVHJhY2vCoHJlc3VycmVjdGVk?= =?utf-8?q?=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mbadra@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org > Nicolas Williams worte: > >> As I see it RFC4507 should terminate all interest in Fast-Track. No? > > They would operate on quite different time scales. > > TLS session resumption (with or without server-side state) requires > storing confidential information (the master secret), and a TLS client > probably won't use persistent storage for it. Also, RFC 5246 suggests > an upper limit of 24 hours for session cache entries. > > The server certificate (and certificate_authorities list), on the > other hand, are not secret, and could be stored (on disk) for months > or years. It is true the master_secret should be protected when storing it. Trustworthy Certificate Authorities cannot easily be falsified. However, attackers that are able to retrive the master_secret may also be able to insert a falsified CA in the list of trustworthy CA, in which the client will accept any certificate issued by the falsified CA. So I think we may have the same problem when we store the CA list on the disk. Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Dec 4 06:41:09 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1CA3A693B; Thu, 4 Dec 2008 06:41:08 -0800 (PST) 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 BAAFC3A693B for ; Thu, 4 Dec 2008 06:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 G8rqvScLH4tf for ; Thu, 4 Dec 2008 06:41:05 -0800 (PST) Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by core3.amsl.com (Postfix) with ESMTP id 166413A6A76 for ; Thu, 4 Dec 2008 06:41:04 -0800 (PST) Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 4 Dec 2008 14:40:55 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.9]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Thu, 4 Dec 2008 14:40:55 +0000 From: Stefan Santesson To: Nicolas Williams , Yoav Nir Date: Thu, 4 Dec 2008 14:40:54 +0000 Thread-Topic: [TLS] TLS Fast-Track resurrected? Thread-Index: AclVouab6INETVlbTWKaNWVMylDrbwAeoJRw Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB4F790B7@EA-EXMSG-C332.europe.corp.microsoft.com> References: <0016364584386e8572045c8e8024@google.com> <200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> <20081203225301.GS22970@Sun.COM> <7264CE19-EFBD-4D1F-82CD-2DEA09C9D7AA@checkpoint.com> <20081203234104.GU22970@Sun.COM> In-Reply-To: <20081203234104.GU22970@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Nico, For some usage of TLS the cost of sending a certificate path is negligible. For others it's not. The problem may be multiplied by transmission errors. For some usages in EAP TLS, this optimization would significantly improve performance. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Nicolas Williams > Sent: den 4 december 2008 00:41 > To: Yoav Nir > Cc: tls@ietf.org > Subject: Re: [TLS] TLS Fast-Track resurrected? > > On Thu, Dec 04, 2008 at 01:30:16AM +0200, Yoav Nir wrote: > > Not really. Fast-Track is for establishing TLS when the old session > > ticket has already expired (maybe it's your first connection for the > > day). It makes the first connection (the one that can't benefit from > > session resumption, stateless or otherwise) take less bytes. > > I got that, but if you're doing session resumption w/o server-side > state > then the cost of one regular TLS handshake will be amortized over many > resumptions, so what's the point of Fast-Track? > > > That said, I'm not convinced it's all that useful without lots of > > assumptions about low bandwidth and charge-by-bytes. Most of us can > > afford to send a certificate chain every few hours. > > Exactly! > > Nico > -- > _______________________________________________ > 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 tls-bounces@ietf.org Thu Dec 4 08:05:37 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8411F3A6AA3; Thu, 4 Dec 2008 08:05:37 -0800 (PST) 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 28CA03A6AA3 for ; Thu, 4 Dec 2008 08:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 P17tfvWcGEsX for ; Thu, 4 Dec 2008 08:05:35 -0800 (PST) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 238013A6809 for ; Thu, 4 Dec 2008 08:05:34 -0800 (PST) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id mB4H5JYt999642; Thu, 4 Dec 2008 17:05:19 GMT Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Thu, 4 Dec 2008 17:02:35 +0100 (CET) Message-ID: <52025.88.164.98.77.1228406555.squirrel@www.isima.fr> In-Reply-To: <9F11911AED01D24BAA1C2355723C3D321AB4F790B7@EA-EXMSG-C332.europe.corp. microsoft.com> References: <0016364584386e8572045c8e8024@google.com><200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp><9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com><20081203225301.GS22970@Sun.COM><7264CE19-EFBD-4D1F-82CD-2DEA09C9D7AA@checkpoint.com><20081203234104.GU22970@Sun.COM> <9F11911AED01D24BAA1C2355723C3D321AB4F790B7@EA-EXMSG-C332.europe.corp.microsoft.com> Date: Thu, 4 Dec 2008 17:02:35 +0100 (CET) From: "Mohamad Badra" To: =?utf-8?Q?Stefan=C2_Santesson=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 04 Dec 2008 17:05:19 +0000 (WET) Cc: "=?utf-8?Q?=C2_tls@ietf.org=C2?=" Subject: [TLS] =?utf-8?b?IFJlOsKgwqBUTFPCoEZhc3QtVHJhY2vCoHJlc3VycmVjdGVk?= =?utf-8?q?=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mbadra@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Hi Stefan, > Nico, > > For some usage of TLS the cost of sending a certificate path is > negligible. For others it's not. > The problem may be multiplied by transmission errors. For some usages in > EAP TLS, this optimization would significantly improve performance. I think we should define a "specific" renegotiation if we really want to specify this major modification of TLS. EAP-TLS relies on the renegotiation to enable privacy, but this increases dramatically the performance and IMO there is no need to establish a full key exchange during the second TLS session when both the client and the server agree on using the so-called Fast-Track. BWT, I still don't see the big advantage of Fast-Track over the OCSP extension. OCSP includes several advantages (e.g., the client will be able to get the current certificate status of the server during the TLS Handshake, which may not be possible with Fast-Track). If more optimisation is needed, this same extension could be redifined (another extension) so the client can send also (instead of the certificate_chain) the Distinguished Name of the CA of its certificate_list; so the server can determine whatever "the to be sent" client certificate is acceptable or not. And if then the certificate request will be sent empty, and otherwise, the server stops the session. The draft says: "The clients rarely connect to numerous TLS servers". Anyone have any data to back that claim? And if this is correct, why don't then rely on RFC5077? Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Dec 4 09:23:17 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D760A3A6A58; Thu, 4 Dec 2008 09:23:17 -0800 (PST) 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 2DFB63A6A27 for ; Thu, 4 Dec 2008 09:23:17 -0800 (PST) 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 oU7ehYoctAwH for ; Thu, 4 Dec 2008 09:23:16 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 210263A68ED for ; Thu, 4 Dec 2008 09:23:15 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id mB4HN9tF020374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2008 18:23:09 +0100 (MET) From: Martin Rex Message-Id: <200812041723.mB4HN8bU004368@fs4113.wdf.sap.corp> To: mbadra@gmail.com Date: Thu, 4 Dec 2008 18:23:08 +0100 (MET) In-Reply-To: <51651.88.164.98.77.1228399493.squirrel@www.isima.fr> from "Mohamad Badra" at Dec 4, 8 03:04:53 pm MIME-Version: 1.0 X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Fast-Track resurrected 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Mohamad Badra wrote: > > Trustworthy Certificate Authorities cannot easily be falsified. However, > attackers that are able to retrive the master_secret may also be able to > insert a falsified CA in the list of trustworthy CA, in which the client > will accept any certificate issued by the falsified CA. > > So I think we may have the same problem when we store the CA list on the > disk. Which CA list are you referring to? The list of certification_authorities from the CertificateRequest handshake message that FastTrack would want to cache is not used for verification of certificate chains by the client, it is only used for selecting an appropriate client certificate. If you're referring to the (persistence of the) clients credentials which IMHO includes the clients trust anchors (usually represented by (CA/RootCA and selected EE) certs, then your observation is correct. If that is not properly protected, the client may loose his entire security. Btw. this also applies to the server. If you operate an SSL Server that accepts clients authenticating with SSL client certificates, then the Servers private key is not necessarily the most critical component. Depending on how client (certs) are mapped to user accounts, the SSL Servers list of trust anchors might be much more critical. However, todays PKI software is usually much better at protecting/hiding private keys than it is at protecting/hiding the list of trust anchors... -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Dec 4 10:24:36 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30203A6BB1; Thu, 4 Dec 2008 10:24:36 -0800 (PST) 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 249273A6BBB for ; Thu, 4 Dec 2008 10:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 CKc-PilU41K3 for ; Thu, 4 Dec 2008 10:24:34 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by core3.amsl.com (Postfix) with ESMTP id 8DAF43A6BB0 for ; Thu, 4 Dec 2008 10:24:33 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-3.sun.com (8.13.8+Sun/8.12.9) with ESMTP id mB4IORTC007884 for ; Thu, 4 Dec 2008 18:24:27 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mB4IOQ9q033874 for ; Thu, 4 Dec 2008 11:24:26 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mB4I8ZBC025650; Thu, 4 Dec 2008 12:08:39 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mB4I8QKC025649; Thu, 4 Dec 2008 12:08:26 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 4 Dec 2008 12:08:26 -0600 From: Nicolas Williams To: Stefan Santesson Message-ID: <20081204180826.GI22970@Sun.COM> References: <0016364584386e8572045c8e8024@google.com> <200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> <20081203225301.GS22970@Sun.COM> <7264CE19-EFBD-4D1F-82CD-2DEA09C9D7AA@checkpoint.com> <20081203234104.GU22970@Sun.COM> <9F11911AED01D24BAA1C2355723C3D321AB4F790B7@EA-EXMSG-C332.europe.corp.microsoft.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <9F11911AED01D24BAA1C2355723C3D321AB4F790B7@EA-EXMSG-C332.europe.corp.microsoft.com> User-Agent: Mutt/1.5.7i Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org On Thu, Dec 04, 2008 at 02:40:54PM +0000, Stefan Santesson wrote: > For some usage of TLS the cost of sending a certificate path is > negligible. For others it's not. The problem may be multiplied by > transmission errors. For some usages in EAP TLS, this optimization > would significantly improve performance. OK, Fast-Track for EAP-TLS makes more sense, thanks. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Dec 4 10:37:04 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AF83A6BA2; Thu, 4 Dec 2008 10:37:04 -0800 (PST) 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 3EEBF3A6A4F for ; Thu, 4 Dec 2008 10:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 ToTxVQMU3EPB for ; Thu, 4 Dec 2008 10:37:02 -0800 (PST) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 435B03A67B2 for ; Thu, 4 Dec 2008 10:37:02 -0800 (PST) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id mB4Jake1962686; Thu, 4 Dec 2008 19:36:46 GMT Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Thu, 4 Dec 2008 19:34:02 +0100 (CET) Message-ID: <52607.88.164.98.77.1228415642.squirrel@www.isima.fr> In-Reply-To: <200812041723.mB4HN8bU004368@fs4113.wdf.sap.corp> References: <51651.88.164.98.77.1228399493.squirrel@www.isima.fr> from"Mohamad Badra" at Dec 4, 8 03:04:53 pm <200812041723.mB4HN8bU004368@fs4113.wdf.sap.corp> Date: Thu, 4 Dec 2008 19:34:02 +0100 (CET) From: "Mohamad Badra" To: martin.rex@sap.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 04 Dec 2008 19:36:46 +0000 (WET) Cc: tls@ietf.org Subject: Re: [TLS] =?utf-8?b?wqDCoEZhc3QtVHJhY2vCoHJlc3VycmVjdGVk?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mbadra@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org > Which CA list are you referring to? > > The list of certification_authorities from the CertificateRequest > handshake > message that FastTrack would want to cache is not used for verification > of certificate chains by the client, it is only used for selecting > an appropriate client certificate. > > If you're referring to the (persistence of the) clients credentials > which IMHO includes the clients trust anchors (usually represented > by (CA/RootCA and selected EE) certs, then your observation is > correct. If that is not properly protected, the client may loose > his entire security. I refer to the second case. Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Dec 4 10:37:40 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E063A6B86; Thu, 4 Dec 2008 10:37:39 -0800 (PST) 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 DA45D3A6B9F for ; Thu, 4 Dec 2008 10:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.732 X-Spam-Level: X-Spam-Status: No, score=-5.732 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 8F4o+O7g0P65 for ; Thu, 4 Dec 2008 10:37:38 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 15C3B3A6B86 for ; Thu, 4 Dec 2008 10:37:38 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mB4IbXp0010646 for ; Thu, 4 Dec 2008 18:37:33 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mB4IbXbu045497 for ; Thu, 4 Dec 2008 11:37:33 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mB4IEG5e025659; Thu, 4 Dec 2008 12:14:16 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mB4IEG62025658; Thu, 4 Dec 2008 12:14:16 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 4 Dec 2008 12:14:16 -0600 From: Nicolas Williams To: mbadra@gmail.com Message-ID: <20081204181415.GJ22970@Sun.COM> References: <0016364584386e8572045c8e8024@google.com> <200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp> <9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> <20081203225301.GS22970@Sun.COM> <7264CE19-EFBD-4D1F-82CD-2DEA09C9D7AA@checkpoint.com> <20081203234104.GU22970@Sun.COM> <9F11911AED01D24BAA1C2355723C3D321AB4F790B7@EA-EXMSG-C332.europe.corp.microsoft.com> <52025.88.164.98.77.1228406555.squirrel@www.isima.fr> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <52025.88.164.98.77.1228406555.squirrel@www.isima.fr> User-Agent: Mutt/1.5.7i Cc: =?utf-8?B?77+9IHRsc0BpZXRmLm9yZ++/vQ==?= Subject: Re: [TLS] =?iso-8859-1?q?=A0=A0TLS=A0Fast-Track=A0resurrected=3F?= 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org On Thu, Dec 04, 2008 at 05:02:35PM +0100, Mohamad Badra wrote: > I think we should define a "specific" renegotiation if we really want to > specify this major modification of TLS. EAP-TLS relies on the > renegotiation to enable privacy, but this increases dramatically the > performance and IMO there is no need to establish a full key exchange > during the second TLS session when both the client and the server agree on > using the so-called Fast-Track. The I-D I looked at yesterday always requires a full key exchange in any Fast-Track case. If you want to avoid key exchanges then use RFC4507. > BWT, I still don't see the big advantage of Fast-Track over the OCSP > extension. OCSP includes several advantages (e.g., the client will be able Fast-Track is about cutting down bandwidth due to sending large cert chains. What does OCSP have to do with that? > The draft says: "The clients rarely connect to numerous TLS servers". > Anyone have any data to back that claim? And if this is correct, why don't > then rely on RFC5077? That was my question. The answer seems to be: a) Fast-Track helps servers, b) Fast-Track helps EAP-TLS. That's good enough for me, though I still think that RFC4507 should suffice most of the time. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Dec 4 10:51:14 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B353A6A64; Thu, 4 Dec 2008 10:51:14 -0800 (PST) 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 859E63A6876 for ; Thu, 4 Dec 2008 10:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 HQOJF5IP-poO for ; Thu, 4 Dec 2008 10:51:12 -0800 (PST) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6493A6A64 for ; Thu, 4 Dec 2008 10:51:12 -0800 (PST) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id mB4JouE4999658; Thu, 4 Dec 2008 19:50:56 GMT Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Thu, 4 Dec 2008 19:48:12 +0100 (CET) Message-ID: <52647.88.164.98.77.1228416492.squirrel@www.isima.fr> In-Reply-To: <20081204181415.GJ22970@Sun.COM> References: <0016364584386e8572045c8e8024@google.com><200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp><9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com><20081203225301.GS22970@Sun.COM><7264CE19-EFBD-4D1F-82CD-2DEA09C9D7AA@checkpoint.com><20081203234104.GU22970@Sun.COM><9F11911AED01D24BAA1C2355723C3D321AB4F790B7@EA-EXMSG-C332.europe.corp.microsoft.com><52025.88.164.98.77.1228406555.squirrel@www.isima.fr> <20081204181415.GJ22970@Sun.COM> Date: Thu, 4 Dec 2008 19:48:12 +0100 (CET) From: "Mohamad Badra" To: =?utf-8?Q?Nicolas=C2_Williams=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 04 Dec 2008 19:50:56 +0000 (WET) Cc: tls@ietf.org Subject: Re: [TLS] =?utf-8?q?=C2=A0=C2=A0TLS_Fast-Track_resurrected=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mbadra@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org > Fast-Track is about cutting down bandwidth due to sending large cert > chains. What does OCSP have to do with that? > You are right, there is no relationship, my mistake:) Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From jgeering@adam.com.au Thu Dec 4 11:24:49 2008 Return-Path: X-Original-To: ietfarch-tls-archive@core3.amsl.com Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A85128C14E for ; Thu, 4 Dec 2008 11:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.102 X-Spam-Level: X-Spam-Status: No, score=-46.102 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SBL=1.551, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, 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 VsfpSYPevFbK for ; Thu, 4 Dec 2008 11:24:49 -0800 (PST) Received: from gw.esp.co.il (gw.esp.co.il [212.199.249.206]) by core3.amsl.com (Postfix) with SMTP id 1062428C13F for ; Thu, 4 Dec 2008 11:24:46 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081204192448.1062428C13F@core3.amsl.com> Date: Thu, 4 Dec 2008 11:24:46 -0800 (PST)

From tls-bounces@ietf.org Thu Dec 4 13:51:11 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D9343A6A64; Thu, 4 Dec 2008 13:51:11 -0800 (PST) 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 2C8A03A6B2C for ; Thu, 4 Dec 2008 13:51:10 -0800 (PST) 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 zvjlL8QyKwzi for ; Thu, 4 Dec 2008 13:51:09 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 1827D3A6A64 for ; Thu, 4 Dec 2008 13:51:08 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id mB4Lp2Y4008783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2008 22:51:02 +0100 (MET) From: Martin Rex Message-Id: <200812042151.mB4Lp1fc022477@fs4113.wdf.sap.corp> To: mbadra@gmail.com Date: Thu, 4 Dec 2008 22:51:01 +0100 (MET) In-Reply-To: <52025.88.164.98.77.1228406555.squirrel@www.isima.fr> from "Mohamad Badra" at Dec 4, 8 05:02:35 pm MIME-Version: 1.0 X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Fast-Track resurrected 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Mohamad Badra wrote: > > BWT, I still don't see the big advantage of Fast-Track over the OCSP > extension. OCSP includes several advantages (e.g., the client will be able > to get the current certificate status of the server during the TLS > Handshake, which may not be possible with Fast-Track). If more > optimisation is needed, this same extension could be redefined (another > extension) so the client can send also (instead of the certificate_chain) > the Distinguished Name of the CA of its certificate_list; so the server > can determine whatever "the to be sent" client certificate is acceptable > or not. And if then the certificate request will be sent empty, and > otherwise, the server stops the session. If the Fast-Track design was simplified in the way I suggested, it would be trivial to combine Fast-Track with both, the OCSP extension and RFC4507. If there is value in caching fairly static information from the full SSL/TLS handshake on the client side, then there is even more value if it is done in a fashion orthogonal to the TLS handshake protocol so that it can be reused for static data of almost every conceivable TLS extension. A much simpler approach through mostly a simple TLS (client) hello extension would also have the benefit that it reduces the necessary code changes and resulting complexity to the protocol engine of an existing implementation. I really wouldn't change anything about the protocol and the handshake message -- only define the representation of a "replacement tag" to send in place of the information that the client already has, and such posession has been confirmed to the server by the inclusion of a matching (tagged) hash for this piece of information in a simple TLS "Fast-Track" hello extension containing a list of tag&hash-value pairs. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Dec 4 14:23:42 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6CB73A6A64; Thu, 4 Dec 2008 14:23:42 -0800 (PST) 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 985903A6A64 for ; Thu, 4 Dec 2008 14:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 FzjkngnlCM24 for ; Thu, 4 Dec 2008 14:23:41 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id D01EC3A6A37 for ; Thu, 4 Dec 2008 14:23:41 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mB4MNZdM006268 for ; Thu, 4 Dec 2008 22:23:35 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mB4MNYr5038782 for ; Thu, 4 Dec 2008 15:23:34 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mB4M7j0x025964; Thu, 4 Dec 2008 16:07:45 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mB4M7UmV025963; Thu, 4 Dec 2008 16:07:30 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 4 Dec 2008 16:07:30 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20081204220730.GG22970@Sun.COM> References: <52025.88.164.98.77.1228406555.squirrel@www.isima.fr> <200812042151.mB4Lp1fc022477@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <200812042151.mB4Lp1fc022477@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: mbadra@gmail.com, tls@ietf.org Subject: Re: [TLS] TLS Fast-Track resurrected 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org On Thu, Dec 04, 2008 at 10:51:01PM +0100, Martin Rex wrote: > If the Fast-Track design was simplified in the way I suggested, it > would be trivial to combine Fast-Track with both, the OCSP extension and > RFC4507. > > If there is value in caching fairly static information from the > full SSL/TLS handshake on the client side, then there is even more > value if it is done in a fashion orthogonal to the TLS handshake > protocol so that it can be reused for static data of almost every > conceivable TLS extension. A much simpler approach through mostly > a simple TLS (client) hello extension would also have the benefit > that it reduces the necessary code changes and resulting complexity > to the protocol engine of an existing implementation. > > I really wouldn't change anything about the protocol and the > handshake message -- only define the representation of a "replacement tag" > to send in place of the information that the client already has, > and such posession has been confirmed to the server by the inclusion > of a matching (tagged) hash for this piece of information in a simple > TLS "Fast-Track" hello extension containing a list of tag&hash-value pairs. +1 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Dec 4 14:39:12 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6BF83A693C; Thu, 4 Dec 2008 14:39:12 -0800 (PST) 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 9D4073A693C for ; Thu, 4 Dec 2008 14:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 9eZHXAZQcInc for ; Thu, 4 Dec 2008 14:39:10 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 785563A691F for ; Thu, 4 Dec 2008 14:39:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,716,1220227200"; d="scan'208";a="120984308" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 04 Dec 2008 22:39:06 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB4Md6L9016518; Thu, 4 Dec 2008 14:39:06 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id mB4Md62J016758; Thu, 4 Dec 2008 22:39:06 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Dec 2008 14:39:06 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Dec 2008 14:38:25 -0800 Message-ID: In-Reply-To: <1696498986EFEC4D9153717DA325CB720276B0CB@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS Fast-Track resurrected? Thread-Index: AclP3jmt4IGDvm+8SQ2SsPkGaCbG/gE1DzawAB6mFLAATNwBoA== References: <0016364584386e8572045c8e8024@google.com>from"ernuzwang@gmail.com" at Nov 26, 8 02:36:56 am<200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp><9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com> <1696498986EFEC4D9153717DA325CB720276B0CB@vaebe104.NOE.Nokia.com> From: "Joseph Salowey (jsalowey)" To: , , X-OriginalArrivalTime: 04 Dec 2008 22:39:06.0064 (UTC) FILETIME=[1D542500:01C95661] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3469; t=1228430346; x=1229294346; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[TLS]=20TLS=20Fast-Track=20resurrected? |Sender:=20; bh=Bm1aMYQvu4SDyulwyRDaTTJszG+Te35SBNt+zchw07M=; b=fjRrb+k3ntFeRbdE3/caXI4J++LXBsLcEVe61gXTZjWWfERai4e2QUYAy2 MCSIEvVMIraE6+lf4BzESVnt5j9/QBGEIYf/wIVZLO0Dica7NmOKdxcCSFDu hXDrgZb5Vt; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org I have seen instances where certificate_authorities have been problematic for certain clients in EAP-TLS. It would be good to have a way to avoid sending all this data as well. Making the solution a bit more generic would be good. Cheers, Joe > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On > Behalf Of Pasi.Eronen@nokia.com > Sent: Wednesday, December 03, 2008 2:15 AM > To: stefans@microsoft.com; tls@ietf.org > Subject: Re: [TLS] TLS Fast-Track resurrected? > > If we do this, I'd suggest also including the > "certificate_authorities" > list from CertificateRequest. If the trust anchor list is > large (as it often is in e.g. typical Windows setups), that's > easily over 3 KB (similar size, or even larger, than the > server certificate chain). > And it's often sent even if the client won't actually use TLS > client authentication. > > A data point: I took a dump of TLS-protected handshake done > by an unnamed Microsoft product (no session resumption, no > client authentication). The TLS handshake messages were 7391 > bytes. With a simple "send SHA-256 hash of server certificate > and certificate_authorities list in ClientHello extension" > design, that would have been about 415 bytes, saving almost 7 > KB (over 90%). > > (If this was just e.g. 25%, it IMHO wouldn't be worth doing > -- it wouldn't be a good engineering tradeoff between added > complexity and saved bytes. But if we save over 90%, that > sounds much better...) > > Best regards, > Pasi > > > -----Original Message----- > > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On > Behalf Of > > ext Stefan Santesson > > Sent: 02 December, 2008 21:27 > > To: tls@ietf.org > > Subject: [TLS] TLS Fast-Track resurrected? > > > > At the last IETF I brought up the question whether we > should bring the > > old TLS Fast-Track work back to life. > > The general opinion was positive. > > > > In short, my proposal is to generate a new draft inspired > by the old > > TLS Fast Track draft > > (http://tools.ietf.org/html/draft-shacham-tls-fast-track-00) > > The new proposal would change the old proposal in the following way: > > > > * Only use extensions. Not defining new Client and Server Hello > > messages > > * Keep general design of the fast-track extension but add hash > > algorithm agility. > > * Reduce determining parameters to be hashed. > > > > I'm open to suggestions on how to, if at all, reduce the old > > determining parameters from Fast Track section 4.1, but I would > > suggest to just hash the server certificate and then do a > normal TLS > > session setup except from not sending over the TLS server > certificate > > if the client has correctly identified the server > certificate in the > > client hello extension. > > > > We may lose some degree of optimization, but would gain in > simplicity. > > > > > > > > Stefan Santesson > > Senior Program Manager > > Windows Security, Standards > > > > _______________________________________________ > > 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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Dec 4 15:50:59 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491F83A6AF4; Thu, 4 Dec 2008 15:50:59 -0800 (PST) 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 7F43A3A6AF4 for ; Thu, 4 Dec 2008 15:50:57 -0800 (PST) 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 4vcNscgd0uPp for ; Thu, 4 Dec 2008 15:50:56 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 84E733A680E for ; Thu, 4 Dec 2008 15:50:56 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id mB4NolK6016459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 00:50:47 +0100 (MET) From: Martin Rex Message-Id: <200812042350.mB4NokKC000161@fs4113.wdf.sap.corp> To: jsalowey@cisco.com (Joseph Salowey) Date: Fri, 5 Dec 2008 00:50:46 +0100 (MET) In-Reply-To: from "Joseph Salowey" at Dec 4, 8 02:38:25 pm MIME-Version: 1.0 X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org Joseph Salowey wrote: > > I have seen instances where certificate_authorities have been > problematic for certain clients in EAP-TLS. It would be good to have a > way to avoid sending all this data as well. Making the solution a bit > more generic would be good. What level of "avoiding" are you referring to? Fast track can not make you avoid the original full SSL handshake entirely, it can only help you to fast-track repeated "full SSL handshakes". The ratio of the original full SSL handshakes vs fast-tracked full SSL handshakes depends on (a) how often the servers fast-tracked information is (administratively) changed and how long the client is willing and capable of caching/persisting a servers fast-trackable information. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From oymfvejtjgy@101-fm.com Thu Dec 4 18:07:50 2008 Return-Path: X-Original-To: ietfarch-tls-archive@core3.amsl.com Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372FC3A6A78 for ; Thu, 4 Dec 2008 18:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.871 X-Spam-Level: X-Spam-Status: No, score=-7.871 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 nL6k4GFJsFXo for ; Thu, 4 Dec 2008 18:07:50 -0800 (PST) Received: from 70.15.210.253.res-cmts.haw.ptd.net (70.15.210.253.res-cmts.haw.ptd.net [70.15.210.253]) by core3.amsl.com (Postfix) with SMTP id 446EB3A6A44 for ; Thu, 4 Dec 2008 18:07:47 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081205020748.446EB3A6A44@core3.amsl.com> Date: Thu, 4 Dec 2008 18:07:47 -0800 (PST)

From tls-bounces@ietf.org Thu Dec 4 22:04:31 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF44F3A6853; Thu, 4 Dec 2008 22:04:31 -0800 (PST) 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 002AF3A67FB for ; Thu, 4 Dec 2008 22:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, 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 RkuQBkq7BXVo for ; Thu, 4 Dec 2008 22:04:29 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2D5C93A6853 for ; Thu, 4 Dec 2008 22:04:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,719,1220227200"; d="scan'208";a="207037823" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Dec 2008 06:04:25 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB564OEc002034; Thu, 4 Dec 2008 22:04:24 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB564OKd018956; Fri, 5 Dec 2008 06:04:24 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Dec 2008 22:04:24 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Dec 2008 21:54:28 -0800 Message-ID: In-Reply-To: <200812042350.mB4NokKC000161@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS Fast-Track resurrected? Thread-Index: AclWayPP0oLDLWcVS+u7IY4xv3Zb4wAMOhNQ References: from "Joseph Salowey" at Dec 4, 8 02:38:25 pm <200812042350.mB4NokKC000161@fs4113.wdf.sap.corp> From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 05 Dec 2008 06:04:24.0733 (UTC) FILETIME=[52E57CD0:01C9569F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1533; t=1228457064; x=1229321064; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[TLS]=20TLS=20Fast-Track=20resurrected? |Sender:=20; bh=XjIMrAyqP9UIcwVxdUhH5CGExIdlDY8Md1It3NYcHOo=; b=JCWdA8vKApPdlpkbGvPvpQcFIE7nQwAna/xccpedpCx4SotiGQAgZc7Br5 EFdz6686B4gAsVK1uBA1MwQvA6ErlS5ZqFYtHEL5+ib1R6ZdEEooY0ha7vcK Q0Ngrn7uWfciW6+f/v5BkmK5FS+NDBf9xY9lrpK6nevwxPi2V9otk=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: tls@ietf.org Subject: Re: [TLS] TLS Fast-Track resurrected? 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-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org > -----Original Message----- > From: Martin Rex [mailto:Martin.Rex@sap.com] > Sent: Thursday, December 04, 2008 3:51 PM > To: Joseph Salowey (jsalowey) > Cc: Pasi.Eronen@nokia.com; stefans@microsoft.com; tls@ietf.org > Subject: Re: [TLS] TLS Fast-Track resurrected? > > Joseph Salowey wrote: > > > > I have seen instances where certificate_authorities have been > > problematic for certain clients in EAP-TLS. It would be > good to have > > a way to avoid sending all this data as well. Making the > solution a > > bit more generic would be good. > > What level of "avoiding" are you referring to? > > Fast track can not make you avoid the original full SSL > handshake entirely, it can only help you to fast-track > repeated "full SSL handshakes". > > The ratio of the original full SSL handshakes vs fast-tracked > full SSL handshakes depends on (a) how often the servers > fast-tracked information is (administratively) changed and > how long the client is willing and capable of > caching/persisting a servers fast-trackable information. > [Joe] The less the better. If the client only had to deal with this rarely (weekly or monthly) that would be an improvement. In many cases the clients have no use for this information even if they are going to do client authentication, so it might be better to have the client signal whether it is interested in this information and include hash if it is interested. > -Martin > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From markaudiod@3mail.com Fri Dec 5 01:52:37 2008 Return-Path: X-Original-To: ietfarch-tls-archive@core3.amsl.com Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B5D3A6C54 for ; Fri, 5 Dec 2008 01:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.396 X-Spam-Level: X-Spam-Status: No, score=-23.396 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, 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 n9PdEq7-1k41 for ; Fri, 5 Dec 2008 01:52:37 -0800 (PST) Received: from 85.137.113.27.dyn.user.ono.com (85.137.113.27.dyn.user.ono.com [85.137.113.27]) by core3.amsl.com (Postfix) with SMTP id CB6D33A6C53 for ; Fri, 5 Dec 2008 01:52:35 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081205095235.CB6D33A6C53@core3.amsl.com> Date: Fri, 5 Dec 2008 01:52:35 -0800 (PST)

From tls-bounces@ietf.org Fri Dec 5 02:57:14 2008 Return-Path: X-Original-To: tls-archive@ietf.org Delivered-To: ietfarch-tls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E1A3A6AFB; Fri, 5 Dec 2008 02:57:14 -0800 (PST) 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 119523A6AFB for ; Fri, 5 Dec 2008 02:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.359, 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 3+nOcNPJyRoY for ; Fri, 5 Dec 2008 02:57:12 -0800 (PST) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id EC30F3A68DE for ; Fri, 5 Dec 2008 02:57:11 -0800 (PST) X-Trace: 168408253/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.235 X-SBRS: None X-RemoteIP: 62.188.105.235 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEAJuXOEk+vGnr/2dsb2JhbACDRIlXwXcHgn4 X-IronPort-AV: E=Sophos;i="4.33,720,1220223600"; d="scan'208";a="168408253" X-IP-Direction: IN Received: from 1cust235.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.235]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Dec 2008 10:57:03 +0000 Message-ID: <001a01c956bf$e7319b60$0601a8c0@allison> From: "tom.petch" To: "Stefan Santesson" References: <0016364584386e8572045c8e8024@google.com><200811261546.mAQFkXYC012389@fs4113.wdf.sap.corp><9F11911AED01D24BAA1C2355723C3D321AB4EB6E03@EA-EXMSG-C332.europe.corp.microsoft.com><20081203225301.GS22970@Sun.COM><7264CE19-EFBD-4D1F-82CD-2DEA09C9D7AA@checkpoint.com><20081203234104.GU22970@Sun.COM> <9F11911AED01D24BAA1C2355723C3D321AB4F790B7@EA-EXMSG-C332.europe.corp.microsoft.com> Date: Fri, 5 Dec 2008 10:42:41 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: tls@ietf.org Subject: Re: [TLS] TLS Fast-Track resurrected? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org ----- Original Message ----- From: "Stefan Santesson" To: "Nicolas Williams" ; "Yoav Nir"